Email list hosting service & mailing list manager

Re: updated version of SRFI 9 Sergei Egorov (31 Aug 1999 04:50 UTC)
Re: updated version of SRFI 9 Richard Kelsey (31 Aug 1999 15:52 UTC)

Re: updated version of SRFI 9 Richard Kelsey 31 Aug 1999 15:52 UTC

   From: "Sergei Egorov" <xxxxxx@informaxinc.com>
   Date: Tue, 31 Aug 1999 00:54:05 -0400

   I agree with your approach to internal record-type definitions
   ("majority of programs won't use them, there is no consensus
   on how to implement them, so they can be left to another SRFI"),
   I am just trying to apply the same logic to the "top-level generativity"
   issue.

It is easy to avoid the generativity issue for internal record-type
definitions - just don't allow any internal record-type definitions.
This won't work for top-level definitions.

   First, I believe that majority of programs won't be relying on
   the fact that defining the same record type twice will give you
   two different record types.

When are two define-record-type forms the same?  When are you guarenteed
to get distinct record types?

   Second, I don't think there is a consensus on the equivalency
   between record types introduced by two identical top-level
   definitions. According to the same logic, this part can be dropped
   from the SRFI.

The two situations are quite different.  Internal definitions are
quite likely to be executed multiple times, under well-defined
circumstances.  The only way I know of executing a top-level
definition multiple times is to capture a continuation at top
level, a somewhat questionable practice.  Because I can write down
the generative semantics (`every execution of a define-record-type
gives a new record type') and I cannot write down the non-generative
semantics (with the possible exception of captured top-level
continuations), I chose the former.

                                        -Richard Kelsey