Formal comment #73 (simplification) Record nongenerative UID should be library name where record is defined Reported by: Aubrey Jaffer Component: records Version: 5.91 Page 66 of R5.91RS suggests the use of "UUID namespace" for nongenerative UIDs, presumably to avoid name conflicts with other record-types of the same name: Note: Users are encouraged to use symbol names constructed using the UUID namespace (for example, using the record-type name as a prefix) for the uid argument. RFC-4122 "Universally Unique IDentifier"s are cryptic to humans. To interchange records between modules, the 36-digit hexadecimal number must be extracted from one and pasted into the source of the others. Were there no other context where Scheme programs needed to resolve external resources, this might be good enough. But R6.91RS libraries must be resolved, libraries which already must contain the record definitions! I propose that a UID argument be either #f or a library-name; and that two record definitions be identified with each other only when their record-names and UIDs match. Going one step further, I propose that generative record-types be removed, and that a #f UID default to the library-name in which this record definition appears. If modules have unique names, then record definitions with a #f UID will not conflict with each other; and record definitions with a #f UID will effectively export themselves for sharing. RESPONSE: There appear to be four subproposals in the formal comment, which we address individually below. 1. Allow or suggest that UIDs be library names: We are unsure whether the proposer meant this to be a requirement or merely a suggestion. We agree with the latter, and the next draft of the R6RS will suggest that programmers construct UIDs either from library names or the UUID namespace. We are not in favor of requiring that library names be used as UIDs, for any of several reasons: - It would force programmers to assign "ownership" of each record type to a particular library, even when the record type definition appears in several libraries. - It would force programmers to change record UIDs whenever the program structure changed and the record type must be given a new owner. - It may require the published UIDs of an application to be changed in some cases where the application's internal library structure changes. - It may break down where local record definitions are concerned, since multiple distinct local record definitions with the same name may reasonably appear in the same library. - It does not generalize to record definitions that appear in programs (known as scripts in R5.91RS), where there is no enclosing library. 2. Make the effective UID a combination of the supplied UID and the record name: We are ambivalent about this but will study the proposal and make a decision by the time the next report draft is released. 3. Treat (nongenerative #f) as an abbreviation for (nongenerative ): We are not inclined to make this change as long as the use of library library names as UIDs is only a convention, and we do not believe that it would be a particularly useful shorthand, given that each occurrence of the record definition outside of the enclosing library must explicitly provide the UID. 4. Eliminate generative record definitions and treat a missing nongenerative clause to be equivalent to (nongenerative #f), i.e., (nongenerative ). We are not inclined to adopt this proposal for the same reasons we are not inclined to adopt proposal 3. Also, we believe that generative record types may be useful and are not inclined to eliminate them at this time. Furthermore, implicit publication of internal record types seems like poor software practice, especially if there is no way to prevent such publication.