Re: RE: succinctness = power

[Matthias Felleisen <address@hidden>]

It is correct that macros implement local syntax transformations.
Indeed, that's one of the points of my expressiveness paper on 
distinguishing the power of languages that can already simulate
Turing machines. 

Having said that, locality does not preculde covering a whole 
bunch of design patterns, assuming you have a powerful target 
language. Two points of interest, since you do write papers on 
this stuff: 

 1. Peter Norvig has a Web site up that explains how many of 
    the GoF patterns "disappear" in CL anyway. By purely local
    means. 

 2. Shriram's dissertation (even earlier than Norvig's Web site)
    includes a chapter on how to express such structural properties in 
    programs via macros. The trick is to have macros with a large 
    enough scope or macros that communicate through "secure" channels. 
    The material also appeared as an ESOP paper (see Publications off
    my Web page). 

Finally, I argue that using NON-local transformations to implement 
patterns as linguistc constructs takes away a lot of explanatory power
from the programmer. It's probably okay if done right. I need to understand
the details first before I comment on your specific approach. 

-- Matthias


At Sun, 26 May 2002 15:35:43 -0700 (PDT), Avi Bryant wrote:
> On Sun, 26 May 2002, Matthias Felleisen wrote:
> 
> > Otherwise Shriram is head-on. Patternistas :) do what Paul does.
> > They just don't understand the role of macros, but some will!
> 
> Many patterns (design and otherwise) don't lend themselves well to being
> captured by lisp macros and similar mechanisms, which are constrained to
> have purely local effects - that is, they can only transform source code
> inside their lexical scope.  Their composability is also quite limited (a
> good example of this is the various CL macros out there that wrap
> defclass; how do you use features from two of them at once?).
> 
> Andrew Catton and I developed a tool called ELIDE last year which allows
> macro-like transformations on Java that don't have these limitations:
> parameterized annotations can be attached to any source construct, which
> trigger transformations whose scope is limited only by the developer's
> good sense.  A trivial example we use is a "visited" annotation on a
> class, which adds both the accept() method to that class and the
> appropiate visit() method to the visitor interface.
> 
> We termed the process of finding patterns and encapsulating them in such
> transformations "Explicit Programming".  More information, including the
> AOSD paper, is available from
> http://www.cs.ubc.ca/labs/spl/projects/explicit.html .