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? William D Clinger 31 Aug 2009 14:25 UTC
Per Bothner wrote: > For Kawa it is desirable to compile a record type to a > class, and to do so at compile-time. This is easier for > non-generative record types. Maybe. With R6RS records, you stil have to record the values of the arguments to make-record-type-descriptor, and perform a run-time check to see whether they're the same as for any previous call with the same uid. You also have to deal with the case where the uid is not the same. I don't think the SRFI 99 semantics adds any complexity to that. With either R6RS or SRFI 99 records, I'd assume that you would want to represent record types by instances of classes, with run-time checks in the accessors and mutators. Those are the checks that the R6RS editors mistakenly believed would be easier to optimize away when the syntactic interface is used. With the structural equality of record types proposed by Shiro, those run-time checks would be far more expensive if the structural equality were tested at accessor/mutator time, and more complicated if done when record types are created. Either way, I don't see how structural equality would make it easier to represent *all* record types by classes instead of instances. I agree that you could use classes to represent record types defined at a library's top level, but that's already true even with the generative semantics of the current draft of SRFI 99. > (I'm not 100% clear on R6RS module semantics. I'm assuming > the actions or definitions of a module are only evaluated > once, even if it is imported multiple times. That's implementation-dependent. You have the right to make that true in your implementation, in which case you can represent top-level record definitions (whether generative or non-generative) by classes. > Inheritance adds a caveat: A record type may need to be generative > if it extends a generative type. At least you have to be > careful you get the correct parent when inspecting. If the parent was generative, but defined by an obvious top-level form, then you can treat the parent as though it were non-generative. I think I'm mostly just repeating what you said. Will