[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: updated version of SRFI 9
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
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
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"
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,
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.)