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/