| Joachim Durchholz 2005-11-07, 10:03 pm |
| Andre schrieb:
> Joachim Durchholz wrote:
>
>
>
> Here is some nice motivation for macros within the context
> of Scheme. Especially section 35.5 and the DSL in chapter 36 are
> of interest:
>
> http://www.cs.brown.edu/people/sk/P...ooks/ProgLangs/
Interesting but ultimately unconvincing.
The arguments he gives are:
1) Providing cosmetics
OK, this one can't be done using HOFs (not easily). You can't clean up
after the language designer made a mess except with macros - the only
option is that the language designer creates a "cosmetic" language :-)
2) Introducing binding constructs
The way out here is a language that has just one class of citizen. I.e.
if everything is a value (including functions, modules and whatnot), you
don't need macros to create constructs in novel ways.
See the Oz language for an example of this. Everything (including
functions and OO classes) is defined as being created at run-time; the
compiler just precomputes a lot of them.
Most FPLs don't go that route; from what I read, I assume that type
inference issues are preventing some of that. (I think type inference is
a bit overvalued - I'd rather err on the side of needing a few
additional type annotations or run-time checks than on the side of
having a less universal language. But that's just me.)
3) Altering order of evaluation
That's the weakest argument. He essentially says that this would require
creating a closure for everything that needs to have its evaluation
deferred, and (rephrasing it in my words) that would to too verbose for
practical use. I think I can agree it would be too verbose in Scheme,
but it certainly isn't in Haskell or SML!
4) Defining data languages
He holds that it's easy to set up large data structures.
In Haskell or Scheme, I'd write functions to set up the data structures,
and assume the compiler would precompute them at compile time. (In
languages without side effects, compilers can aggressively precompute:
replacing a function call with its result is mostly safe operation.)
In other words, the ordinary language is already a data language as
needed. Applying macros for that purpose is just an optimisation
(ironically, he's warning against exactly that idea, using macros as an
optimisation vehicle...).
5) Automata building
Um... the usage of tail call optimisation to set up efficient automata
in an FPL doesn't seem to be very macro-specific to me, so I don't
really see how this justifies macros...
In all, I don't see many reasons for macros in general.
They may be useful in Scheme. I don't know enough about Scheme to have
any fixed opinion on the matter; the best approximation of Scheme that I
ever used was Interlisp, which is rather dated expertise (if one would
like to consider that as "expertise" in the first place).
However, if I were to design a language, I'd leave macros out and make
everything first-class values instead. I'd remove an entire language
layer in one fell swoop, without losing anything too valuable - seems
like a good trade-off to me!
If I were to choose a language, I also wouldn't make the presence or
absence of a good macro system a criterion. The real criteria are
elsewhere: conciseness, learning curve, scalability, ability to formally
encode program properties (i.e. a static type system or better), library
availability, etc. etc. etc. (This list isn't in any particular order.)
Regards,
Jo
|