[langsmiths] macros bad ... uh, no

[Brian T Rice]

Hi Jecel,

It's always good to hear from you. :)

Note: I'm cross-posting this to the Slate mailing list, since it's of
interest to them as well.

On Thu, 28 Nov 2002, Jecel Assumpcao Jr wrote:

> On Thursday 28 November 2002 02:41, Brian T Rice wrote:
> > On Thu, 28 Nov 2002, broncowitz wrote:
> > > I find it ironic that so many of these people who want to make
> > > languages more powerful have, at the same time, the often
> > > opposing goal of making the language simpler for idiots to use.
> >
> > LL2 is full of irony that way. Everyone there is pedantic and
> > pontificating, but the conference exists because "languages for smart
> > people" lost to Python, Perl, Lua, and the like.
>
> While there were two talks about persistence, my favorite issue ("blue
> print" vs "living" systems) was totally missing. I guess that systems
> that need to carry around a whole environment (memory dump, image,
> workspace, snapshot, whatever...) can't be called "light weight",
> though my current work might be proof that they could.

Well, part of the proof seems to include getting a lot of people to use
and accept such a system, which if I am not mistaken has not really taken
hold of a major mindset except in the Lisp and Smalltalk communities. So
there's some challenge to bring this to everyone else in a way that they
will accept as a better way to work.

How is your current work improving this, by the way?

> Anyway, ignoring this issue made the macro discussion pretty silly.
> Macros, and other generative stuff like Aspect weaving, are fantastic
> tools in blue print systems (which are generated from the source on
> each execution) but make no sense at all in living systems (which
> continue to run even as the sources are being changed). It is like the
> difference between gene splicing to create new creatures vs gene
> therapy for adult individuals.

Well, being able to deal with code on a more abstract level than passing a
compiler a string (even if within a living environment as Squeak does)
makes your tools more compact and powerful. In biological analogy, if your
organism has its genes encoded in more flexible encoding, that makes the
gene therapy that much simpler to go about doing. And we are creating
these living systems for now, so it somewhat behooves us to think with
that in mind for the time when the bootstrap process is lost to time.

As for generative programming, it does seem like a dead-system shadow of
the much better work in meta-object protocols. As an example, look at the
very interesting differences between AspectJ and AspectS. AspectS is quite
a bit more powerful and has no need of these ridiculous aspect languages;
it simply uses aspect libraries.

> The problem with the idea that an average person might not understand a
> solution that uses macro is: would that person understand any solution
> at all? My guess is "no", but that person might understand the macro
> based solution as long as he treats the macro as a black box and
> doesn't try to figure out how it does its job. After all, that is how
> he deals with the built in features of the language, right?

That's a very interesting perspective.

> Just because many people can't create macros or figure out how those
> created by others work is not reason not to have them in a language.
> Let a few special people create the macros which the rest can then
> learn how to use. See TeX-->LaTeX.

I also like this approach. It's as important to develop the right social
attitude about a feature as it is to design the feature properly itself.
(Latex macros happen to be things that can often be rather dirty, so it's
a good example of that principle.)

> The real reason to avoid macros is when the strict order they imply
> (edit source --> expand macros --> compile code and objects) no longer
> works because you are editing the source for things which already
> exist. Take Slate, for example. It is currently being used essentially
> as a blue print system (as was Self from 1.0 to 3.0) and so macros work
> wonderfully. If it grows into a graphical, persistent environment they
> might become a problem.

This is a very good point, and it's one I've been concerned about.
Basically our attitude is that macro creation will be generally be
reserved for situations where closures and continuations and such will not
do. But the goal with them until Slate is "living" is to build up useful
domain-specific languages implemented by code transformations. This will
still be relevant in a living system; actually a lot of the code directly
used for the macro-expansion facility is directly re-usable for code
refactorings. My favorite part that makes this possible is that the `
syntactic directive is distinct and separable from the base language, so
we can eventually put everything into tools and then cut that part out of
the language later as we can.

Finally, our eventual goal is syntactic abstraction at least from the
level of text. The Slate macro concept gives us a boost in that direction.

As for the edit-->expand-->compile cycle and how that fits into living
systems metaphors, I don't see a current system that gets beyond that, so
I'll not be dissappointed if we have to deal with those issues. :-)

> "Remember kids: a baby alligator might seem like a good idea for a
> pet..."
>
> -- Jecel

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water at tunes.org
http://tunes.org/~water/