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