[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why generative?
In March of this year, Shiro Kawai wrote:
> This may be too late for discussion, but I just wonder why
> make-rtd should be generative....
> The reason I can think of is that we need a way to create a
> distintive type. But that can be achieved easiliy without
> requiring make-rtd generative, as I describe later.
> An alternative idea is to change definition of identity of
> rtd. What if we define two rtds are eqv? if they have the
> same NAME, FIELDSPECS and eqv? PARENT? (If we extend rtd to
> have sealed and/or opaque flags, we compare those flags as
> well). In other words, we make make-rtd behave
> functionally, meaning it returns eqv? objects for equivalent
> set of arguments.
That could be done, but it's more complicated.
> In order to get distinctive types, we can add one more
> member to rtd; let's say it uid. It is an arbitrary Scheme
> object and is compared by eq? when comparing two rtds. Then
> we can guarantee distinctive type by passing an object that
> can't be eq? to other objects, such as (cons #f #f).
In both drafts of SRFI 99, as in the R6RS library document,
the uid argument is used to specify non-generative record
types. You are proposing to reverse that by using the uid
to specify generative record types. That presupposes some
generative source of uids, such as cons.
> This scheme seems to have advantages over R6RS way when we
> want non-generative behavior: (1) It makes bookkeeping of
> rtd's identity implicit, as opposed to the explicit identity
> specified by R6RS. The R6RS way effectively introduces a
> separate namespace for rtd, which doesn't seem to "fit" to
> other parts of Scheme spec, at least to me. (2) It
> eliminates the need of something like UUID in some cases
> for non-generative make-rtd.
With regard to (1), it seems to me that your proposal also
introduces a separate global table, although it isn't a
"namespace" because it involves hash-consing (using eqv?
identity) on *all* arguments to make-rtd. That's more
complicated, and more fragile with respect to inadvertent
retention, than maintaining the smaller table whose entries
represent only the non-generative record types, and are
indexed by uid symbols.
So I don't see the advantages to your proposal, and I do
see some disadvantages.