The #macro directive is something that's always been trivial to write
in WM, and something which I've never written, because it's never had
a clear enough benefit for the level of complexity that it adds. WM's
develpment has been characterized by careful decisions. Don't rush off
into feature land just because it's possible. There are all sorts of
things that are easy/fun to implement and very wrong. A #while directive
would be another example of something that is easy and wrong.
Obviously the Macro expansion concept is a very important and potentially
powerful one. WM got its name from the idea that it would have a #macro
directive. And it still might some day--but not until I'm damn sure
that I've broken down the problem space correctly. This is the kind
of thing you can't really decide or figure out in a week or two.
I also don't think I would choose to represent macros the way you
are. I also don't think much of putting ()'s around the arguments,
there are better and cleaner solutions that don't do as much damage
to the elegance of the syntax.
In fact, I'd go so far as to say the ()'s are totally pointless. There
isn't any circumstance in which they're needed for correct parsing of
a directive. In order to avoid treating newline as a directive terminator
you've had to add two ugly characters to every directive. It really
adds absolutely nothing to the power of the language, and you have
to admit it's ugly.
The #macro thing deserves a *lot* of thought before implementing it,
and the () decision should be reversed, since it has no value.
Justin
On Wed, Oct 04, 2000 at 09:41:58PM -0700, Daniel L. Rall wrote:
> "Geir Magnusson Jr." wrote:
> >
> > I guess re the complexity issue, no, I personally don't believe that,
> > within limits. Because nothing but template code is used, the toolset
> > really isn't expanded : they can't do any more damage than they can with
> > cut and paste...
>
> Heh. Ever worked with Active Server Pages? Designers pretending to be
> programmers can do a *lot* of damage. (JSP has very similar problems.)
> --
>
> Daniel Rall <[EMAIL PROTECTED]>
