Re: for

[Paul Haahr <haahr@mv.us.adobe.com>]

> >but also add some precedence rules and have the grammar reconfigure itself  

> >on the fly.  i'd call it close to state of the art, as well as a substantial  

> >redesign for our current yacc-driven interpreter.

> Look through the comp.compilers archives.  This kind of thing was done
> in the 1970's.  Current beliefs are, apparently, that this is Not Good.

for a general purpose programming language, i would agree.  but go look at the  
parse.y from es (or even the much cleaner one from rc) and tell me if you think  
that it's obviously the right thing.  the syntax rewriting we're doing right  
now happens in a very ad hoc way, and i think it would be a Good Thing if we  
could generalize it.

> If you're gonna provide macros, then use macros for everything, throw
> away all of the current syntax (rather, rewrite it in terms of the macros)
> and use a single notation throughout.

that's what we'd do.  i'd hoped i'd conveyed that in me previous message.

> Do macros really provide that much more than functions + es's quoting
> rules + eval?  I dunno.

i dunno either, but this whole discussion got restarted by someone suggesting  
moving for outside of the grammar, and you really do that (and keep the same  
semantics) without adding some syntactic extension mechanism.  if you want to  
call that mechanism macros, fine.

> I do know that I'd hate to see defmacro and , and
> ` without good reason.

well, there are more attractice schemes (npi) than defmacro, and the  
extend-syntax one i've been referring to is real nice.

please note, this is all very speculative.  until we either find or invent a  
system that allows us to replace all our current rewriting without seriously  
affecting the user-visible syntax, we're not going to add anything.

paul