On Sat, 2006-05-06 at 00:02 +0200, Martin Kuehl wrote:
> Damn, macros again :-)
> I'll definitely take a look at the revival, but I really doubt I'm the
> one to take on first-class macros just yet.  I seem to have a hard
> time reasoning about them instead of CL macros (or maybe I just
> confuse them too much with Haskell-style pattern matching, i'm not
> sure), and that's something I'd want to change before dealing with
> their compilation.

Guile's built in macros are unhygenic, and work in the same way that
Common Lisp macros do.

A few weeks ago I spent a few hours in the eval code, and it looks like
the big thing that still needs doing is making memoization and macro
expansion eager (macroexpand + memoize an entire expression before
beggining to evaluate any part of it instead of waiting until the
evaluator evals the statement itself like it does now).

Once that is done then the first part of the eval should be split into a
compiler, and the second half into the actual eval step. Then it would
be relatively trivial to drop a new compiler/executor into Guile (if I
understood the code correctly). All the new backend would need to do is
understand the primitive operations that the macroexpander/memoizer
produces.

-- 
http://unknownlamer.org
AIM:unknownlamer IRC:unknown_lamer@fnode#tpu Jabber:clinton@hcoop.net
I use Free Software because I value freedom over features.
443E 4F1A E213 7C54 A306  E328 7601 A1F0 F403 574B