[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Ratification vote for R7RS-small
- To: Sam TH <sam@x>
- Subject: Re: [Scheme-reports] Ratification vote for R7RS-small
- From: John Cowan <cowan@x>
- Date: Fri, 26 Apr 2013 09:33:41 -0400
- Cc: scheme-reports@x
- In-reply-to: <CAK=HD+YiSU5L0Qgtz68GqRELrmtq6abF8NDMvNiyJykr+3-dSA@mail.gmail.com>
- References: <CAK=HD+YiSU5L0Qgtz68GqRELrmtq6abF8NDMvNiyJykr+3-dSA@mail.gmail.com>
Sam TH scripsit:
> SRFIs are not standards,
If you want to get technical, the only *standard* for Scheme is IEEE
1178. Some SRFIs are not even de facto standards, it's true, but many
are: documents like SRFI 1, SRFI 9, and SRFI 23 are clearly "established
by consensus and approved by a recognized body that provides for common
and repeated use, rules, guidelines or characteristics for activities or
their results, aimed at the achievement of the optimum degree of order
in a given context", which is the ISO definition of a standard. See
> Breaking compatibility with them is not the same as breaking
> compatibility with the ratified Scheme report.
People tend to refer to R7RS-small as "R7RS", as if it were by itself
the intended successor to R6RS, but it isn't. R6RS compatibility was
never a goal of the R7RS-small report by itself, a point frequently
overlooked. Language was added to R7RS-small on page 3 to address this.
> Also, the module system breaks compatibility with existing R5RS
> programs because giving a portable semantics to R5RS-style top-level
> programs is impossible.
If that were really true, there would be nothing to break compatibility
with, since the impossible cannot exist.
> "the top level is hopeless" for more here , or more on point, the
> fact that R7RS makes no attempt to actually standardize any of the
> hard cases here.
Standards are contracts between users and implementers, telling
the users what they can rely on and what they can't. It is not a
requirement that a standard prescribe everything, and even much more
prescriptive standards such as ECMAScript don't attempt to.
> Finally, the R6RS module system addresses important and challenging
> problems that R5RS did not, which R7RS instead abandons.
As noted above, this is a misuse of the term "R7RS". Since the small
language does not have low-level macros, there was no need to address
phasing. It will be addressed in some fashion in the large language.
> R6RS was forced to break backwards compatibility because
> fully-compatibly moving forward from R5RS was not possible.
That depends on what direction you think "forward" is.
> R7RS demonstrates this by breaking compatibility again in some of
> these areas, and by not moving forward in most.
This is an equivoque: R7RS-small has indeed moved forward from R5RS,
and does not significantly break compatibility with it.
John Cowan http://ccil.org/~cowan cowan@x
The Penguin shall hunt and devour all that is crufty, gnarly and
bogacious; all code which wriggles like spaghetti, or is infested with
blighting creatures, or is bound by grave and perilous Licences shall it
capture. And in capturing shall it replicate, and in replicating shall
it document, and in documentation shall it bring freedom, serenity and
most cool froodiness to the earth and all who code therein. --Gospel of Tux
Scheme-reports mailing list