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.
Sergei Egorov has suggested that SRFI-9 be less specific. He would like the following three issues to be left to the implementation: - Whether record-type definitions with the same name are disjoint. - Allow internal record-type definitions without specifying whether they are generative or not. - Whether SET!-ing any of the bindings introduced by a record-type definition has any effect on any other bindings. 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. 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. 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. -Richard Kelsey