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.
From: "Sergei Egorov" <esl@xxxxxxxxxxxxxxx> Date: Thu, 2 Sep 1999 01:26:02 -0400 Two record types are guaranteed to be distinct if the corresponding <type name>s are different. If more than one define-record-type forms use the same <type name>s, the behavior of such a program is unspecified. Do you mean <type name> considered as a name or <type name> considered as a symbol? Suppose I define my own record macro that does not include a <type name> and expands into DEFINE-RECORD-TYPE: (define-syntax define-my-record-type (syntax-rules () ((define-my-record-type . stuff) (define-record-type this-type . stuff)))) All of my record types might turn out to be the same. In any case, I think it would be a bad idea to introduce a new name space. I believe this guarantee is enough for the majority of programs. But why isn't the generative semantics enough for all programs? INCLUDE and configuration languages are red herrings. There is lots of generative behavior in Scheme; if this poses a problem, then INCLUDE should include each file at most once. Trying to patch up all of the generative features is not going to work. Should the same top-level call to CONS return the same pair when a file is included twice? Historical note: Common Lisp's DEFSTRUCT designers faced the same problem and decided to left the behavior unspecified. Some details can be found in CLtL2 p.473 and X3J13 DEFSTRUCT-REDEFINITION:ERROR vote: http://www.harlequin.com/education/books/HyperSpec/Issues/iss118-writeup.html As far as I can tell they would be more in agreement with my position than with yours. From that web page: Cost to Users: It is doubtful that any current programs actually define structures more than once. Thus, constraints on DEFSTRUCT redefinition primarily affect the debugging environment. Aethetics: Something that is not well-defined and leads to erratic behavior should be explicitly considered an error. In other words, allowing a non-generative redefinition of the same type is not well-defined but is useful for debugging. I am happy to allow non-generative redefinition for debugging. I want to disallow it in programs, where it has no clear meaning or utility. -Richard Kelsey