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

[Jonathan Bachrach <address@hidden>]

matthias,

i* never said that having a lightweight lambda notation _eliminates_
the need for syntactic abstraction.  i said instead that macros become
less necessary.  i said that many of the common** uses of macros can
be conveniently expressed in this lightweight lambda notation (e.g.,
smalltalk's blocks) without resorting to macros.  that was my point
and a point i think is worth making.  i even go on to say that clearly
there are other situations where macros are the only mechanism by
which a programmer can hide syntactic implementation details (and can
greatly benefit by syntactic abstraction***).

programmers are lazy and having lightweight lambda notation makes
programmers more apt to use them.  perhaps lisp would be an entirely
different language if lambda notation were lighter weight.  in this
other world, perhaps lisp might have ``if'' be a function**** which
take two thunks, a consequent thunk and an alternant thunk:

  (defun max (x y) (if (> x y) { x } { y })

as is done in smalltalk.  i wouldn't imagine that programmers would
put up with:

  (defun max (x y) (if (> x y) (lambda () x) (lambda () y)))

but would quickly write a macro to make this more convenient and less
obfuscated.  this is obviously just one example.

jonathan bachrach

ps. wow.  i shouldn't have presumed people knew, but actually i have
thought about _this_ and have even written papers on macro systems
(including ones for languages without sexpr-based syntaxes where
arguing for macros is crucial) and am definitely an advocate of
macros.  believe it or not, to a large extent i was trying to play
devil's advocate to this macro mania and represent matz' viewpoint
because i felt his point was not so easily heard nor understood.  just
to bolster my case, my current language, goo (www.googoogaga.org), has
macros in it as well as a light-weight lambda notation.

* my views do not necessarily represent my employer's views (nor matz'
  (nor even my own if things get much more heated)).

** obviously people's mileage will vary, but i am speaking of the most
   common uses of macros as witnessed by macros offered as part of
   lisps and those presented in On Lisp (by paul graham).

*** technically i didn't say this but meant to imply it.

**** perhaps a generic function with two methods for the consequent
     and alternant cases.  smalltalk implements ``if'' as a method on
     booleans.  details don't really matter, but now i'm feeling like
     i have to be a lawyer and compulsively cover my butt.

Matthias Felleisen <matthias@ccs.neu.edu> writes:

> Macros exist for the very same reason that lambda exists (or Lambda): 
> to abstract over patterns. 
> 
> lambda abstracts over values. 
> Lambda abstracts over types. 
> Syntax abstracts over syntax. 
> 
> A phase separation (theorem) should ensure that all three of them 
> abstract at the right time and in a way that doesn't affect later 
> time: 
> 
> lambda was easy. 
> Lambda took some time, but if you devise the calculus properly 
>  (called XML way before other guys grabed those letters), you 
>  can work that out. This gives us Functors and ParaPolymorphism 
>  in ML. 
> Syntax took some time, but I think Matthew Flatt's paper @ ICFP
>  nailed this one. 
> 
> All of these of course abstract relative to some core language, 
> and then the expressive power of that core language matters. 
> 
> To claim that just because lambda x. is spelled \x. eliminates 
> the need for syntatic abstraction is equivalent to the claim
> that just because emacs is good at copy/paste and keyboard
> macros we don't need function definitions in any programming
> language. 
> 
> Think about this. -- Matthias

Jonathan Bachrach <jrb@ai.mit.edu> writes:

> 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