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

Re: why generative?

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

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
per@xxxxxxxxxxx   http://per.bothner.com/