[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why generative?

This page is part of the web mail archives of SRFI 99 from before July 7th, 2015. The new archives for SRFI 99 contain all messages, not just those from before July 7th, 2015.

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.