[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updated version of SRFI 9

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