On Sun, 7 Nov 2004 xxxxxx@autodrip.bloodandcoffee.net wrote:

> It is because the implementation performs such heavy syntax-rules-based
> computation that Scheme48's heap overflows.  You can 'fix' the problem
> by increasing the heap, but that will solve it only temporarily.  The
> real problem is that this SRFI's reference implementation just does too
> much with syntax-rules;

I agree that it is a little silly to try to do so much with syntax-rules.
Actually, early versions without inheritance were much simpler and very
suitable for syntax-rules, and when it grew it took less energy each time
to add a feature than to convert to a low-level macro system for which I
would have to maintain a separate version for each Scheme I want to test
it on (although I do have a partially converted but horrid-looking and
verbose syntax-case version).

Also, if one version was to be posted as proof of concept, choosing
syntax-rules was probably not entirely a bad decision.  If I had done it
in a low-level system, I would have probably chosen define-macro
or syntax-case, in which case it would not have run on Scheme48 at all
without some porting.

> even if it doesn't overflow the heap or so
> something equally horrid in other Scheme systems, it is _miserably_
> sluggish.  I haven't used it much, but I've heard from some people that
> it takes up to an hour to expand a single DEFINE-RECORD-TYPE form.

One could argue that those systems are not /usefully/ R5RS compliant.
There is really no excuse for that kind of performance.  On Petite Chez,
which is interpreted, expansion is instantaneous.  Even on MzScheme,
which I regard as relatively slow, it takes of the order of only a second
per record type definition on my modest machine.

> It
> would be a *gargantuan* improvement to provide at least two or three
> reference implementations: the original one in plain syntax-rules, one
> in syntactic closures (as the most simply expressive, I argue, hygienic
> macro system -- the best basis for a _reference_ implementation), and
> perhaps one or two in any number of the incompatible variants of
> syntax-case.

I completely agree.  Any volunteers?  The soon-to-appear updated version
is a little simpler and may be easier to convert.  In the meantime I
can send it privately to anyone upon request.  It should also not be hard
to write a low-level implementation from scratch.

Regards
Andre