Re: why generative?

[William D Clinger <will@xxxxxxxxxxx>]

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