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 30 Aug 2009 20:25 UTC

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
   re-exporting).
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.)
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/