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.
This may be too late for discussion, but I just wonder why make-rtd should be generative. (I posted my question to comp.lang.scheme a few days ago but it seems that the newsgroup is very quiet recently?) 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. Since rtds are immutable, an implementation doesn't actually need to compare their components to test type identity. For example, make-rtd can be memoizing and returns eq? rtd for exactly the same arguments, or make-rtd calculates some kind of "type signature" symbol from its arguments so that two rtds can be compared by simply comparing them. We can leave actual optimization strategy to implementors. 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). 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. Whether the higher-level syntactic layer should be generative or not is another problem. If programmers generally expects distinctive types for every define-record-type, then we can specify that it expands into make-rtd with passing unique object to uid by default, with optional syntax to give the uid. Non-generative use case such as efficient local record definition can just pass something like #f to uid, and the compiler can recognize it and generate efihficent code. At worst, if you need local record definition *with* distinct type, you can pass UUID uid, which is no worse than R6RS. Is there a flaw in this idea? Are there any definitive reason I'm not aware of that make-rtd should return a fresh rtd by default? --shiro