Someone asked:
>  How, exactly, does one hope to maintain a system of any size or
>  written by a group of any size where each component is written in its 
>  own "pluggable" syntax?

I note that extensible languages have been around for quite a while,
but they generally seem to have fallen into this pit.

It's possible to have something like TEI, where you come up with a small
number of base syntaxes, and have a whole bunch of modules you can plug
in, and you can even customise the result by renaming elements and adding
your own.

On the other hand, multilingual projects are nothing new.
Quintus Prolog, in the mid-80's, used Prolog, Progol (a high level
macro processor/assembler), C, MockLisp (for Emacs), and Xerox Lisp,
plus we allowed people to plug in Fortran and Pascal, so we had to
test those.  That's code in seven languages within one project.

The limiting factors appear to be
 - each language must be well defined and *documented*
 - the interfaces between the languages must be straightforward
   and ideally should be *checked* in some way (e.g. Quintus Prolog's
   foreign function interface could automatically be compiled into C
   calls for the purpose of lint checking, CORBA is typed).
 - the division of code between languages should be *large* chunks.

So   
	>Subsystems.  Interfaces.
is dead right.
	
Fine-grained variation within a single language,
at anything other than the lexical/layout level,
is risky.

Scheme's "hygienic macros" are at first sight a
counter-example.  However, they introduce compilation-order
dependencies between parts of programs that would be rather
unusual in Smalltalk.  If you change the definition of a macro,
all the code that uses it must be recompiled, because it might
not be syntactically valid any more.  That's ok in Scheme,
because the language standard does not define an interactive
environment, so batch compilation works.  (Some Scheme systems,
but not all, do offer an interactive environment, so they do
have to worry about this problem.)