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

Re: Macros Make Me Mad




Neel,

This is a very nice analysis.  I remember years ago hearing someone say
that lisp programmers only care about ugly syntax for the amount of time
that it takes to write a macro that packages it up into nice syntax.

Given that, I'm curious as to why needle doesn't use s-expression syntax.
For me, the big win with sexps is that macros don't look any different from
standard function calls; only the evaluation is different (I'm excluding
read-macros here).  My suspicion is that in a non-sexp-based syntax with
operator precedence etc., macros would be much more likely to become
incomprehensible.  But I don't know this from experience, so maybe some of
the Dylan or Rebol folks can chime in with their experiences.

Incidentally, the thing that scares *me* about macros is debugging code
that involves a lot of macros.  Can the debugger know enough about the
macro definitions to allow the user to debug transparently without having
to look at big macro expansions all the time?  Considering that C++
debuggers have trouble dealing with simple macro-like constructs such as
templates (or at least they used to) I assume that this is a non-trivial
problem.

Mike

> From: Neel Krishnaswami <neelk@alum.mit.edu>
> Date: Fri, 15 Nov 2002 21:01:14 -0500 (EST)
> 
> Todd Proebsting writes:
> >
> > Despite the fact that many folks I respect swear by macros, I've yet
> > to feel comfortable with them in a language.  Since LL2, I've been
> > trying to figure out what my resistance is based on.
> >
> > Defining a macro is often an act of defining a language construct
> > and implementing it.  Reasonably or not, I hold language constructs
> > to a higher standard than, say, a mere function definition. 
> >
> > Are these technical reasons?  No.  But they are practical reasons,
> > and ultimately I program practically.  Macros may be great for
> > individuals and small groups, but I just don't believe that they
> > scale for these non-technical reasons.
> 
> For me, macros are a prerequisite for getting the leverage I need to
> get Needle to where I want it to be.
> 
> My idea is that a lot of really powerful techniques -- combinator
> parsing, logic programming, etc -- don't get used because users hate
> extra downloads. If, say, 70% of the people with a need will download
> the package that solves it, then adding a prerequisite package wil
> drop the number of people willing to get both down to 49% of the
> people with the need. That's no good. So they just have to be in the
> standard library (this is the Java lesson).
> 
> Now, both of these are pretty easy to encode in a functional language
> with higher-order functions: you can write a combinator library for
> parsing and use call/cc to implement backtracking. However, while
> these encodings are formally perfect, they aren't very much fun to use
> because the syntax gets grotty. A library with a grotesque syntax,
> even if it's in the standard library, won't get used nearly as often
> as it should be.
> 
> That's where macros come in. They turn ugly syntax into beautiful
> syntax. I plan on writing a GUI library which lets you use an
> HTML-like hierarchical sublanguage to lay out widgets. And they can
> turn *no* syntax into *some* syntax. For example, I also plan on
> adding a SQL-like sublanguage, which will transparently get turned
> into ODBC calls. The parsing process can do the checking needed on the
> SQL, which the bare string-passing style can't.
> 
> All of this would be much more work and less flexible if I had to
> modify the compiler to add each library. Now, I'll admit that I'm not
> really addressing your question. I just don't know whether macros will
> "scale up" -- I've never worked on a multi-million LOC project so I
> have no frame of reference. But in some sense that doesn't matter,
> because I can't reach my goals *at all* without them. Half a loaf is
> better than none, surely!
> 
> 
> Examples of good sublanguages:
> 
> o Schelog: Prolog in Scheme
> 
>   <http://www.ccs.neu.edu/home/dorai/schelog/schelog.html>
> 
> o DUIM: Dylan User Interface Manager
> 
>   <http://www.functionalobjects.com/products/doc/dguide/index.htm>
> 
> o Oracle PL/SQL:
> 
>   <http://info-it.umsystem.edu/oradocs/doc/server/doc/PLS23/toc.htm>
> 
> o Perl 6 parser patterns:
> 
>   <http://www.perl.com/lpt/a/2002/08/22/exegesis5.html>
> 
> -- 
> Neel Krishnaswami
> neelk@alum.mit.edu
>