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.
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. Yes, exactly. > > 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 won't occur. 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? --shiro