Re: are dylan macros Turing-complete?

[Bruce Hoult <address@hidden>]

In article <elgl87kf60.church.of.emacs@localhost.verbum.private>,
 Colin Walters <walters@verbum.org> wrote:

> Bruce Hoult <bruce@hoult.org> writes:
> 
> > Really?
> > 
> > What does the "setf" macro expand to in your favourite Lisp compiler?
> 
> Sorry.  I meant that Lisp's `defmacro' can perform arbitrary
> computation in Lisp to compute a macro expansion, while the Dylan
> macro system appears to be restricted to recursive pattern matching.
> This is an important conceptual difference between the two, I think.

I agree.


> I note in my paper that despite this, the Dylan macro system appears
> to be able to express the majority of transformations that defmacro
> can.

Perhaps substitute "the majority of transformations that defmacro is 
commonly used for"?

There are certainly useful things that you can't do wth Dylan macros, 
but perhaps they are uncommon in practice.

Clearly Dylan can duplicate the CL "loop" macro.

Someone suggested a couple of years ago that Dylan can't implement the 
"series" macro.  I downloaded the source code for "series" but it was so 
extensive that I didn't have the time to attempt to translate it.

Something that Dylan macros clearly can't do conveniently is arithmetic.  
They can generate expressions that the compiler will 
compile-time-evaluate later on, but they can't make decisions or control 
loops based on that arithmetic.  It's possible to fake that using Church 
numerals or Turing Machine methods, but that's a pain.  It would be 
possible to implement decimal arithmetic within the macro system, but 
once again that would be a pain.  And somewhat pointless.


I've started going through the newly-released online copy of _On Lisp_, 
noting what there can and can't be applied to Dylan.  Unfortunately 
progress is slow, due to work commitments at the moment.


There is apparently a procedural macro system in 
Harlequin/Functional-Objects Dylan, which is used internally in the 
system but not documented.


My own philosophy on the use of macros is that they are not for doing 
computation, but merely for rearranging the surface syntax so that the 
programmer can write something in syntax convenient to their application 
domain, and that is transformed into concrete code that implements their 
abstraction.  If this process requires optimization then that should 
take place in the compiler proper.

I find the ability for a single macro to expand into methods added to 
any number of Generic Functions to be incredibly powerful.  I don't 
think this is matched by any other language other than CL.  To me this 
is key to a large part of the power of Dylan macros and, combined with 
Dylan's sealing declarations and a powerful optimizing compiler, can do 
many things efficiently that would otherwise require full programmable 
code generation such as "aspects".

-- Bruce