Re: Incomplete compiler?

"Uwe Altenburg" <Uwe.Uta.Altenburg@t-online.de> wrote:
>I would like to know, if there is a compiler (and a language) where I
>tell the compiler in the source-code how to compile the source? Let's
>say an "incomplete" or "simple" compiler that can be extended if
>needed or is this a "perpetuum mobile"?
...
>[Look at the work done in the 1970s on extensible languages, where
>you could add BNF and semantics right in the middle of your program.
>It seemed like a cool idea but turned out to be useless. -John]


At least at the time: Languages and therefore compilers have in the past
not been so advanced that they are in the need of extensible grammars.


By contrast, computers are now so powerful, that there is no problem
adding complex computer languages. It becomes more reasonable to have
different syntax for different contexts.


One such an application that comes to my mind is a successor to a program
like TeX, with the added capability of understanding different
mathematical syntaxes (perhaps linked up to symbolic math and CLP). --
Mathematicians do use different syntaxes, and it would be convenient to be
able to plug those formulas into a program, and the program checks for
accuracy, rather than one is doing the transformation oneself in the head.


Another applicable context might be computer languages that have a wide
range of applicability: I followed the development of Haskell somewhat,
and there they had the problem of which syntax shortcuts to allow -- they
tend to clash. This clash is then a consequence of insisting on using only
one syntax for the whole language.


I think that mathematicians resolve such clashes by just settling for a
few simplifications that are suitable for the math at hand. This suggests
that one should allow user customization of syntax in more advanced
computer languages.


One should note that the more general this extensibility is, closer to
BNF, the harder it is for the user to plug in a custom syntax. So allowing
operator precedence and such more restricted methods seems to be more user
friendly.


Also, a language like TeX, which is "extensible", in reality seems to make
use of an underlying fixed grammar, by which one set some parameters on
how the input should be interpreted with respect to this fixed grammar.
One shortcoming of this approach is that it looks more general than it is.
So the unassuming programmer may start program for implementing more a
more general syntax, and then will get stuck due to the limitations of the
language.


So, for efficient extensibility, there seems to be a balance one should
follow: More general becomes more difficult to program; too special, and
one cannot plug in the syntactic constructs that one wants.


    Hans Aberg * Anti-spam: remove "remove." from email address.
                                    * Email: Hans Aberg <remove.haberg@member.ams.org>
                                    * Home Page: <http://www.matematik.su.se/~haberg/>
                                    * AMS member listing: <http://www.ams.org/cml/>
[The problem with 1970s extensible languages wasn't that they didn't work,
it was that adding more syntax on the fly didn't solve any real problems,
and I don't think that's changed. Overloading like C++ and TeX provide
seems a lot more promising. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.