[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why generative?
From: William D Clinger <will@xxxxxxxxxxx>
Subject: Re: why generative?
Date: Sun, 30 Aug 2009 13:12:22 -0400 (EDT)
> 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.
Not necessarily. If simplicity is important, you can
just return a new structure from make-rtd. When comparing
rtds, the simplest way is to compare element-by-element
(just like comparing complex numbers, for example. that's
how "functional" objects should be compared, semantically.)
If performance is important, complexity generally increases.
> > 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.
No, not at all. As I described above, the proposed
semantics do not require any global mechanism.
> 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.
Using tables is one way to optimize comparison. If an
implementation wish to use the table, I suppose it already
has tables with weak references, hence inadvertent retention
Another optimization strategy may be that the implementation
calculates a hash value from rtd fields and cache it in an rtd.
Either way, it is an implementation detail.
> So I don't see the advantages to your proposal, and I do
> see some disadvantages.
Do you still see disadvantages? (except that the proposal
reverses the meaning of the current spec).
What I think as an advantage is: I assume nongenerative rtds
are the norm, and generative ones are exceptional. Putting
the burden of specfying extra information (uid) to the
rarer use case certainly has an advantage.
Or, is my assumption wrong?