Email list hosting service & mailing list manager

the number of fields soo (07 Nov 2004 12:20 UTC)
Re: the number of fields campbell@xxxxxx (07 Nov 2004 16:27 UTC)
Re: the number of fields Andre van Tonder (07 Nov 2004 17:33 UTC)
Re: the number of fields campbell@xxxxxx (07 Nov 2004 19:35 UTC)

Re: the number of fields campbell@xxxxxx 07 Nov 2004 20:03 UTC

On Sun, 7 Nov 2004, Andre van Tonder wrote:

> 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.

That would not be the case had you chosen syntactic closures, which
fairly easily translate to explicit renaming and which allow much more
straightforward representation of the interaction of hygiene than
syntax-case; thus a syntax-case implementation could easily be based on
syntactic closures.

> > 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.

I don't think MzScheme & Petite Chez are good examples: if I'm not
mistaken, MzScheme's macro expander is written in C and Petite Chez's
is compiled with Chez, which is generally reputed to be one of the best
Scheme compilers out there.  In any case, I don't remember the details
of the expansion time -- the Scheme system used, the number of fields,
et cetera --, and my memory probably exaggerated the time somewhat;
however, it was certainly longer than a few minutes, an unreasonable
quantity of time.

> > 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.

I volunteer to write a syntactic closures-based implementation, as long
as you don't mind me pestering you about details of the hygiene.