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

Re: C++ Templates used like Dylan Macros

On Tue, Mar 28, 2000 13:04 Uhr, Hugh Greene <mailto:q@tardis.ed.ac.uk>
wrote:
>I found the following article in C++ Report (March 2000, Vol 12/No 3) 
>rather interesting -- dunno if anyone else will but what the hell :-). 
>It's the first part of a look at a way of using C++ templates like Dylan
>macros, i.e., leaning towards exploiting them for code generation, rather
>than just type specialisation. 
>
>  http://www.creport.com/html/from_pages/column_mar.shtml
>
>(probably eventually to be archived at
>  http://archive.creport.com/0003/html/from_pages/index.shtml
>or
>  http://archive.creport.com/200003/html/from_pages/index.shtml
>guessing from their other archive pages).
>
>It's interesting that some of the problems are similar -- unenlightening
>error messages and "it takes getting used to" in particular!
>
>C++ folks who get their heads around this will get an idea of what macros
>are good for in Dylan -- they're nothing like C preprocessor macros, being
>"grammar-aware".  Dylaners might get some macro design ideas and/or good
>ideas for macros.
>
>-- Hugh
>

Yes. Template metaprogramming is a very powerful tool for code generation.
Here comes a link to a sophisticated macro system (called staged
computation) that has been implemented as an ML dialect. It supports the
creation of code fragments with holes and allows to fill in the holes at
runtime and then run the code fragment.

http://www.cse.ogi.edu/~sheard/sheard.html

Below is an old post to this group (info-dylan) that I just digged out. It
contains come design ideas for procedural macros and combining of code
fragments.
Maybe the time has come to begin thinking about these ideas again and start
a design.

	Gabor


##############################################
From:	Kim Barrett <kab@camellia.org>
Subject: Re: Lisp-style macros
Cc:	info-dylan@harlequin.co.uk
Sender: owner-info-dylan@harlequin.co.uk

> Date: Tue, 25 Aug 1998 18:37:08 +0100
> From: Jeff Dalton <jeff@aiai.ed.ac.uk>
> Subject: Lisp-style macros (was Re: Free source for Apple Dylan -- any
>chance?)
>
> There seemed to be an issue of Lisp-style ("written in the language
> itself") macros vs macros in Dylan.  Arguments against Lisp-style
> macros often mix in arguments that turn out, on closer inspection,
> to be about something else, such as Lisp in general, Common Lisp,
> typical Common Lisp implementations, or particular features of
> Common Lisp.
>
> It's important to be clear that Lisp-style macros can be free of
> problems that stem from such things as particular features of
> Common Lisp.
>
> That a powerful language feature can be misused is, however,
> nothing new.  And, as before, when using the file-compiler in
> the usual way, the development env is gone by the time the
> application runs.  There is therefore no intermingling of
> the dev env with the app env.
>
> When I write Lisp code, the typical situation is somewhat different.
> Compilation and execution are done in separate processes, with
> separate address spaces, that do not share global variables.

I completely agree with all of the above points Jeff made.  (I edited out
a bunch of additional points in the discussion that aren't relevant to the
rest of what I'm going to say here.)

I am quite certain that the only reason Dylan does not have a more powerful
macro facility that includes user-written code to construct expansions was
a resource issue:  the group of people (at various organizations) who were
working on the language design simply didn't manage to devote sufficient
effort to the problem.  I don't recall anyone involved in the language
design being opposed to such, and many (if not most or all) would have in
fact preferred that they were there.  There was even a basic understanding
of how much of it should work, but there wasn't time or energy available to
work out the details.

Here is an outline of the design that was being considered (as I remember
it -- note that I don't think most of this ever got written down in any
coherent fashion, just talked about by a number of interested parties).

- The model is syntax-case, from Scheme.

- Augment the existing macro facility by allowing executable code to appear
on the right-hand side of macro expansion rules.

- The pattern variables in the left-hand side template are bound to the
appropriate code fragment objects (or sequences of code fragment objects)
around the right-hand side expander body.

- There is a class hierarchy for code fragments, and a set of protocols for
examining and constructing code fragments, and for examining and
manipulating
the compiler's model of the runtime environment.  (That is, code fragments
are structured, rather than being basically arbitrary lists as in the CL
macro model.  The compiler's model of the runtime environment might be
captured within the code fragment objects rather than being a separate
object along the lines of the syntactic environments present in CL.)
(Note that using typed objects rather than unstructured lists
prevents/avoids
some representational "punning" that we found (and found rather confusing)
in
some of the syntax-case examples we looked at.)

I believe Harlequin's DylanWorks contains something that looks a lot like
this buried inside its implementation.  I would be quite unsurprised to
learn that Gwydion Dylan contains something similar.  Apple Dylan, because
of its implementation technology (it was not implemented in Dylan, rather
it was implemented using MCL) only contains pieces of this, and in a form
that might not be easily accessible from Dylan.

Obviously that sketch leaves a lot of details to work out, such as the
precise class hierarchy and protocols for manipulating code fragments.

The only tricky part left is figuring out how to arrange for the compiler's
execution environment to be augmented with user code that is associated
with
the library being compiled.  There were a number of suggestions discussed,
but I think most or all of them eventually resolve down to being
essentially
equivalent to something like CL eval-when :compile-toplevel, as far as the
user is concerned.  Obviously there are lots of implementation details...

By the way, I think that Gwydion Dylan would be a great vehicle for working
on this problem.  I wish I had time to devote to it, but if someone else
decides it would be an interesting problem to work on, I'd be happy to
discuss ideas.