[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: choosing a language for your audience or macros vs syntax?



Bruce Lewis <brlewis@alum.mit.edu> writes:

> Ken Anderson <kanderson@bbn.com> writes:
> 
> > ....macros were basically free because we needed them to implement the
> > special forms anyway.
> > ....
> > Syntactic extension carries a lot of issues with it, but isn't it
> > essential for growing a language?
> 
> This is a very Schemey (LISPy?) way of looking at building a language.
> If you start off with the basic building blocks of variables, literals,
> procedure calls, lambda, conditionals, and assignments, then it seems
> the only natural strategy is to create a macro system to extend those
> basic building blocks into a full-blown language.
> 
> However, if you leave lambda out of your list of basic building blocks
> and think of it as an advanced feature to add later, then a macro system
> becomes much less interesting.  The most interesting and useful macros
> involve lambda.
> 
> I think a lot of language implementors don't look at lambda as a basic
> building block.
> ...

perhaps another view (which i think matz was making) is that if you
make lambda notation sufficiently lightweight, then macros also become
less interesting (or necessary).  look at smalltalk (and now ruby)
with its succinct block notation.  this makes expressing control forms
(e.g., for, while, ...)  using lambda palatable to programmers.
scheme tries to be lambda-centric with its forms (e.g.,
call-with-input-file), but unfortunately its lambda notation is so
verbose that programmers would rather wrap them up in macros (e.g.,
with-input-file).  i'm not saying that all things that macros offer
could be succinctly handled with convenient lambda notation but it
does cover a surprising number of the most common uses.

i've been experimenting with a succinct lambda notation in goo, and it
seems to have been popular with early users.  once you have a succinct
lambda notation then you're encouraged to also rethink your library
api.  for example, it becomes tenable to pass a lambda argument to
functions (e.g., fill or elt) that would otherwise expect merely an
initial or default value.

jonathan