[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: updated version of SRFI 9

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

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.)

-- Sergei