[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why generative?
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.
I'm guessing most record-types will be created by a top-level
or module-level define-record-type. I'm assuming those can
be optimized or treated as non-generative.
(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. I don't see
where this is stated explicitly, but it seems to be implied
by this statement in chapter 7:
An identifier can be imported with the same local name
from two or more libraries or for two levels from the same
library only if the binding exported by each library is
the same (i.e., the binding is defined in one library, and
it arrives through the imports only by exporting and
So it should be OK to compile a module-level define-record-type
or make-rts as if it were non-generative.)
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.
Kawa does add one complication: A module is compiled to a java class.
The top-level or module-level definitions can be compiled into either
static or instance (non-static) fields of the module class, depending
on various options. The idea is you can have multiple independent
"Scheme application environments", for example in a server, and these
should not stomp on each other's variables. So each application can
have a separate mapping from module (compiled to a class) to module
instances. So does a module-level record type need to be generative
if the module is non-static? Yes, in principle. But as long as
the type does not have type-level state, and each record type belongs
to a separate application environment, then it seems like we can
treat the record-type as non-generative. (It's different if a
record-type can have methods, and these methods can access to
module-level non-static variables.)