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: >... >The problem with this approach is that any program that makes use >of something explicitly unspecified is not portable. R5RS is >already rife with unspecified behavior (does DEFINE introduce a >binding, order of argument evaluation, CHAR->INTEGER encoding, >inexact numbers, and so forth). People are bitten by these all >the time. Code that runs perfectly in N implementations fails in >the N+1st. I don't know if this is the right place to discuss the drawbacks and benefits of underspecification, but there *are* benefits and that's why the unspecified behavior is in R5RS (people bitten for writing non-portable programs is just the most visible benefit :-). > >The SRFI mechanism provides a good alternative. SRFI-9 gives a >minimal specification. SRFI-X can be identical, except that >it allows internal record-type definitions that are generative, >while SRFI-Y allows them and makes them non-generative. The >majority of programs probably will not use internal record-type >definitions and can run in implementations that provide SRFI-9, >-X, or -Y. Programs that do use them can require SRFI-X or -Y, >making it clear which semantics is needed for that particular >program. 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. 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. 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. I know that my wishes can be satisfied by some SRFI-Z, identical to SRFI-9 in all respects but leaving the top-level generativity issue unspecified; I just don't want to start the "I don't like this word" schism leading to multiple almost identical SRFIs. > >Another issue Egorov raises is the interaction between genericity >and program debugging. To my mind this is a metalinguistic area >in which implementators are free to do whatever they like. >Reloading a program or part of a program may create new record >types or it may reuse the old ones. The SRFI deals with the >semantics of programs, not with how they are run or debugged. This is not a remote "metalinguistic" area; as soon as I started using the Chez INCLUDE syntax form (discussed at the Baltimore workshop, http://www.schemers.org/Events/Workshops/Sep1998/minutes), the top-level generativity issue become exposed semantically even in very simple configurations (this issue is familiar to every C/C++ programmer; I am not advocating any solution here, I just want to note that the issue is more complicated than it seems.) -- Sergei