Email list hosting service & mailing list manager

Re: why generative? William D Clinger (30 Aug 2009 17:12 UTC)
Re: why generative? Per Bothner (30 Aug 2009 20:50 UTC)
Re: why generative? William D Clinger (31 Aug 2009 14:25 UTC)
Re: why generative? Per Bothner (31 Aug 2009 15:22 UTC)
Re: why generative? Shiro Kawai (31 Aug 2009 08:23 UTC)

Re: why generative? Per Bothner 31 Aug 2009 15:21 UTC

To clarify: I'm not arguing for a change to SRFI-99.
I was trying to see if my understanding that it seems
reasonably straight-forwardly and efficiently implementable.

There are 3 implementation strategies to use, and it I
think I'd want to use all three:

(1) Run-time generation of a java.lang.Class, using the
Java ClassLoader.defineClass mechanism.  This is appropriate
when the field-specifiers are non-constant.  An RTD is
just a java.lang.Class, and record-rtd is just getClass.
This is of course fully generative.

This seems like a straight-forward extension of the
existing make-record-type mechanism (as in MIT Scheme).

(2) Compile-time generation: When the field-specifiers
are constant, the parent is known, and it is explicitly
or implicitly non-generative.  Top-level record type
definitions can usually be implemented this way.  An RTD
is again just a java.lang.Class.

Again, this seems like a straight-forward extension
of already-implemented functionality.

(3) A hybrid, when the field-specifiers are constant,
but the record type is generative.

In this case you represent a RTD using a class with
two fields: a java.lang.Class, plus a pointer to the
parent RTD.  The Class is compiled at compile-time.
Each time make-rtd is evaluated we create a new instance
of the RTD class, but it points to the Class created
at compile time.  You need a field in each record that
points to the RTD instance, and record-rtd returns that.

Kawa implements something similar as PairClassType.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/