Lauri Alanko wrote:
> The first Scheme implementation whose internals I studied was
> Guile. It is nominally a branch of SCM, but I don't know how much in
> common they had then (or have now, nine years later). But I do recall
> that the "interpreter" -flavour of the implementation made macros (and
> the evaluator in general) exceedingly hard to understand. Macros were
> represented as procedures that didn't evaluate their arguments, and
> whose return values were cached so that each expansion happened only
> once. So Guile was in effect still living in the pre-80's FEXPR- and
> MACRO-ridden Lisp world.
>
> First encountering such an implementation seriously hindered my
> understanding of how Scheme's syntax works, and I still cannot think
> of any redeeming value for such an approach. It certainly didn't make
> Guile's internals any simpler.
>
That's an interesting and useful report, gets low-level facts right, and
displays
a reversal of valence from my account that I respect.
It may improve the quality of your educational experience from that
code if you consider how it relates to implementation techniques for
lazy functional languages (graph rewriting techniques). From that
perspective, SCM and Guile (at least back in the day) are essentially
a hand-compiled partial evaluation of a simple Scheme compiler
coded in a lazy, functional style, composed with a simple, imperative
and eager-style graph-code interpreter. (I want to suggest some
Peyton-Jones writings as a starting point for reading but am momentarily
too lazy(!) to give a specific reference.)
Just because SCM and Guile draw on some older and currently
out-of-fashion design patterns doesn't mean that they're random
spaghetti-code without good theoretical and engineering justifications
and explanations. Macro hygiene is one of the great innovations
to come out of the Scheme world and should be more widely
appreciated and used, but, the world doesn't revolve around it
and promoting it to too high a status is surely a distortion.
> So I don't see a compelling reason why R6RS should go out of its way
> to support implementations with such an approach.
>
>
>
It is hard to convey concisely, to be sure.
-t
> Lauri
>
> _______________________________________________
> r6rs-discuss mailing list
> r6rs-discuss_at_lists.r6rs.org
> http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
>
>
Received on Wed Mar 07 2007 - 18:11:04 UTC