This page is part of the web mail archives of SRFI 9 from before July 7th, 2015. The new archives for SRFI 9 contain all messages, not just those from before July 7th, 2015.
Richard Kelsey writes: >... > DEFINE-RECORD-TYPE is generative: each use creates a new > record type that is distinct from all existing types, including > other record types and Scheme's predefined types. I might represent a very small portion of Scheme community that thinks that nongenerativity has some benefits of its own, but for few of us, it's a pity to lose a perfectly good SRFI because of just one phrase. I believe that for most applications the choice of generativity / nongenerativity doesn't matter because records are only defined once. From the other hand, traditional interactive load-test-edit-reload cycle becomes easier if existing record objects can still be recognized by the corresponding predicates after reloading of the edited source file. My old implementation of records used the following trick: make-record-type first checked if the type being registered has been registered before by checking the corresponding entry in *record-type-table*. If the record was already there and the field list was equal? to the new one, the old record type was reused; otherwise, the new record type was created and put into the table. This implementation was nongenerative by default, but allowed for several useful options to help in interactive debugging: before reloading the source file, any number of entries could be removed from the table; this made the system "partially generative". Alternatively, one could set the *record-type-table* variable to #f thus disabling all table operations and turning the system into "fully generative" mode. I call this a trick because the programs I used to write were not dependent on the generativity/nongenerativity of the implementation; they never defined the same record type twice. However, having meta-linguistic control over generativity issues made interactive debugging much easier. Fixing the "generativity" issue either way once and for all makes my implementation nonconforming. I would be much happier if instead of the strict generative wording, this SRFI used something like this: Records are disjoint from the types listed in Section 3.2 of R5RS. Record types produced by record type definitions with different <type name>s are disjoint. The relation between types produced by two record type definitions with identical <type name>s is implementation-dependent. > > Record-type definitions may only occur at top-level (there are two > possible semantics for `internal' record-type definitions, generative > and nongenerative, and no consensus as to which to use). There is the third choice: allow `internal' record-type definitions, but leave the generativity of such definitions explicitly unspecified. Again, many useful programs can be written, which do not rely on this property of the implementation. > > - SET!ing any of the bindings introduced by DEFINE-RECORD-TYPE should > not affect the original values of the bindings. I can hardly imagine anyone who can benefit from the knowledge that set!ting :pare from your example to something else won't affect the behavior of kons and kar; it seems to me that requiring this property from all implementations will legalize this questionable practice instead of discouraging it. Leaving some aspects of behavior explicitly unspecified is an underestimated but very useful technique... Sergei