On Thu, Oct 24, 2002 at 12:26:41PM -0300, Adriano Nagelschmidt Rodrigues wrote:
> Luke Palmer writes:
> > Lisp is implemented in C, and C's macros are certainly not essential
> > to its functionality.  But think of what macros in general provide:
> > 
> >       * Multi-platform compatability
> >       * Easier maintenance
> > 
> > Perl has no problem with the former.  It's multi-platform by nature.
> > But is has as much of a problem with the latter as any other language,
> > except Lisp.  That is one of the continuing strong points of Lisp: it
> > can change very, very quickly.
> 
> Yes. And what would this kind of "meta programming" allow? Perhaps thoughts
> like this:
> 
> "Now I need code for these n cases. I will just write a macro."
> 
> Maybe it makes complex problems suddenly appear more "tractable", allows for
> more code reuse/factorization?

Damian's Switch.pm is like a Lisp macro.  It extends Perl syntax for a
certain kind of problem, and makes it easier to write a common code
pattern.  The thought process might go something like this:

        "I want to check a variable against a variety of conditions, and
        I'm tired of writing the same long-winded and error prone
        if/elsif/elsif/elsif/else cascade.  This is a common 'switch'
        statement, except that I want to match a variety of conditions
        intelligently (integers, string equality, regexes, etc.)."

When Paul Graham writes that 25% of his Viaweb code was macros,
he's really saying that Common Lisp wasn't well suited to his
problem domain (writing an ecommerce app).  However, Common Lisp
*allowed* itself to be extended in that directon, with macros.
The result is that the 75% of his code that comprised the guts of
Viaweb could have been written without macros (or in a language
other than Common Lisp), but would have taken significantly more
effort and code (and led to more bugs).

Perl source filters are similar to Lisp macros to a small degree.
Lisp macros are Lisp functions that are invoked at compile time to
transform a *tokenized* Lisp program (using Lisp data structures)
into a different set of tokens (which are then compiled).  Source
filters tend to act on raw text, not tokenized source code, and
need to deal with the problematic aspects of Perl syntax (comments,
Pod, HEREDOCs, etc.) every time they are written/invoked.

Because Lisp macros are real Lisp code, they are far more powerful than
the textual substitutions that pass for "C macros".

Perl6 is moving to include something like Lisp macros.  Perl5 source
filters are a rough approximation, and a preview of things to come.

Z.

Reply via email to