[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: the number of fields

This page is part of the web mail archives of SRFI 57 from before July 7th, 2015. The new archives for SRFI 57 contain all messages, not just those from before July 7th, 2015.



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

> On Sun, 7 Nov 2004 campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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.