[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the number of fields
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.
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.
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
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.