Re: Python gets macros - now XML does too

From: Adrian Kubala (adrian_at_sixfingeredman.net)
Date: 01/05/05 

Date: Wed, 5 Jan 2005 02:19:25 -0600

Manuel Lemos <mlemos@acm.org> schrieb:
> MetaL compiler flow module provides support for level 0 (macro
> expansion) metaprogramming but IMO that is a very limited form of
> metaprogramming.

Not in Lisp. In Lisp, with macro expansion you can do arbitrary
source->source transformations, using the full power of Lisp to do so.
Which I think is what you mean by:

> The real power comes from level 2 metaprogramming features and
> eventually beyhond. Level 2 means that you write a code specification in
> an high level syntax. That that specification is translated into MetaL
> level 1/level 0 XML source code, which gets translated to the final
> target language of choice.

I guess the special thing about Level 2 is the translation can be
arbitrarily complex, which is true of Lisp macros. And in practice, Lisp
macros are often used to implement the "compilation" of a high-level
domain-specific language as you describe.

> Despite currently I only use PHP because I only develop Web
> applications, I don't know about the future. If I need to switch to
> another target language, I just need to develop the lower level
> translation modules of MetaL to support another language, and so my
> current work supporting PHP applications will not be wasted.

Something about this doesn't make sense to me, but it's hard to put my
finger on it. It just seems like, to whatever degree two languages are
different enough that you'd choose one over the other, it would be that
much harder (and pointless) to create one source file that generates
good libraries for both. Like if you use Java it's probably because you
want packages, Swing, the JVM, threads, or static typing, and if you use
PHP it's probably because you want dynamic typing, eval, builtin
bindings for every useful-for-web-apps C library in existence, and so
on, and by programming in MetaL you get neither.

There's opportunities for convergence but I personally think it's at the
level of the virtual machine, and even there you get impedance
mismatches -- there's complaints that all the .Net CLR-supported
languages are just superficial variations on C#, and you can bet we'll
never see a good Haskell->CLI compiler.

Relevant Pages

  • Re: Two questions together
    ... How powerful are the macros? ... > "programmable language" and as far as I know this feature is provided ... It is also said that one can hammer the Lisp so that ... I really love Lisp's syntax:) But I just want ...
    (comp.lang.lisp)
  • Re: macro for shorter array syntax
    ... How is OCaml on adding readmacros, which Lisp can do easily. ... I would not ask that of a parsed language. ... We're confident that using macros is useful to us, ... debate has legitimate points on both sides. ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... but then Ruby is dog slow anyway: ... Having notational convenience via macros plus efficiency is a big win ... From my perspective as a Ruby programmer learning Lisp, ... thought of having a more powerful language *and* orderof magnitude ...
    (comp.lang.lisp)
  • Re: A "killer" macro
    ... Or perhaps Lisp doesn't have one thing ultra- ... with a prefix language. ... the only thing that *really* sets Lisp apart is macros. ... Ruby and C# are very different. ...
    (comp.lang.lisp)
  • Re: macro for shorter array syntax
    ... reason I turned to Lisp is that many, or even most, people in the C++ ... it is also a good idea to be careful with adding new macros. ... Hence an ideal language for implementing an interpreter for Simulink models would allow one to define block types directly, like e.g. so: ... So the actual implementation of the functionality provided by define-node-type is mostly achieved through functional libraries, MOP hackery, etc., and it is indeed still possible to define new node types by hand via defclass, defmethod and various globally-defined macro helpers, but a node definition is much more concise. ...
    (comp.lang.lisp)