Related articles |
---|
extending a grammar maatwerk@euronet.nl (1996-03-12) |
Re: extending a grammar foggia@amalfi.dis.unina.it (1996-03-21) |
Re: extending a grammar platon!adrian@uunet.uu.net (1996-03-25) |
Re: extending a grammar mw@ipx2.rz.uni-mannheim.de (1996-03-27) |
Re: extending a grammar franka@europa.com (1996-03-27) |
From: | franka@europa.com (Frank A. Adrian) |
Newsgroups: | comp.compilers |
Date: | 27 Mar 1996 00:08:56 -0500 |
Organization: | ancar technology |
References: | 96-03-082 96-03-135 |
Keywords: | parse, design |
foggia@amalfi.dis.unina.it (Pasquale Foggia) wrote:
>As far as I know, there are at least two such languages still in use:
>1) lisp, with defmacro, allows to rewrite an expression in an almost
> arbitrary way before its evaluation. This is made possible by
> the fact that lisp expressions have the same structure of data,
> and thus can be processed using other lisp expressions.
> The drawback is that, in order to preserve this property,
> new expression types created with defmacro cannot be too much
> different from the traditional ones (i.e., full-parenthesized
> prefix expressions).
The last part of this statement is not correct. Because a macro in
LISP can be invoked on any character in the input stream, it is
possible to create completely arbitrary grammar extensions - without
parens, even - as can be attested to by many attempts to create
non-LISP syntax expression parsers within the system. The most robust
and full-featured one I'm aware of was in the InterLISP system. BTW,
for historical interest, most of these attemps have been unmittigated
failures. I guess when you've reached syntactic Nirvana, there's no
going back :-)
There was also an article a couple of years ago by some guys at
Microsoft who were dinking with adding computational macros to C++ (it
was either in the OOPSLA, LISP & FP, or DIMPL proceedings). It looked
like a horror.
>I agree with our moderator that an extensive use of these features
>can quickly lead to write-only programs.
However, their JUDICIOUS use is far too powerful to be ignored..
Frank Adrian
franka@europa.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.