ERR5RS: extending the R5RS
William D Clinger
expand its reach to include selected features of the
R6RS. We are developing ERR5RS using a wiki hosted
at the SchemePunks site:
http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter
There is urgent need for the community to become
involved in developing and supporting this project,
lest the R6RS precipitate a crisis of portability by
encouraging every R5RS system to invent different ways
to add different subsets of the desirable features of
the R6RS.
Portability is the primary motivation and requirement
for ERR5RS.
Portability across extended implementations of the R5RS
is one goal.
Another goal is to provide greater portability between
the two incompatibly different kinds of Scheme programs
that now exist. ERR5RS will make it easier to convert
traditional Scheme code into R6RS libraries, and will
also make it easier to convert R6RS libraries into
ERR5RS code. To achieve this goal, ERR5RS will use
subsets of R6RS syntax and semantics wherever possible,
inventing new syntax and semantics only for essential
features that were omitted from the R6RS.
At the same time, ERR5RS will avoid some excesses and
mistakes of the R6RS. Portability would not be enhanced
by making ERR5RS gratuitously difficult to understand or
to implement. As the R5RS is extended, every added
feature should pay its own way by improving portability
of user programs more than it degrades portability by
confusing programmers or by discouraging implementors
from implementing ERR5RS.
That is not to say that all new features of ERR5RS will
be implementable by portable R5RS code. On the other
hand, designs that can be implemented easily by most
implementors of the R5RS will be preferred over
alternatives that would be harder for them to add.
Finally, ERR5RS will show respect for Scheme's tradition
by preserving backward compatibility unless there is
substantial agreement that today's and tomorrow's new
requirements require some of yesterday's code or books
or research papers to be rewritten or abandoned.
We invite your help and support in developing,
implementing, and using ERR5RS.
[signees in alphabetical order]
André van Tonder
Chris Hanson
David Rush
Harold Ancell
Jonathan Rees
Nils M Holm
Onnie Lynn Winebarger
William D Clinger
fee...@iro.umontreal.ca
> We invite your help and support in developing,
> implementing, and using ERR5RS.
I welcome your initiative. May I suggest that you consider as soon as
possible a portable way of distributing Scheme code packages? This
does not have to be part of the ERR5RS spec, but the ERR5RS should
make it easy. I'm thinking of something like the Snow framework. In
fact I'm hoping the Snow framework can be adapted to the syntax of
ERR5RS and the current packages upgraded to that syntax.
Marc
William D Clinger
> I welcome your initiative. May I suggest that you consider as soon as
> possible a portable way of distributing Scheme code packages? This
> does not have to be part of the ERR5RS spec, but the ERR5RS should
> make it easy. I'm thinking of something like the Snow framework. In
> fact I'm hoping the Snow framework can be adapted to the syntax of
> ERR5RS and the current packages upgraded to that syntax.
We are too, as you can see by the reference to Snow in
http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:SRFIs_and_Standard_Libraries
We would welcome your help in using Snow as a distribution mechanism
for ERR5RS reference implementations and libraries.
Will
uti...@gmail.com
Lynn Winebarger
> ERR5RS is an expeditious revision of the R5RS that will
> expand its reach to include selected features of the
> R6RS. We are developing ERR5RS using a wiki hosted
> at the SchemePunks site:
>
> http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter
>
> or http://tinyurl.com/2g3r4q
http://www.scheme-punks.org/wiki/index.php?title=ERR5RS:Charter
also works.
Lynn
Ray Blaak
> ERR5RS is an expeditious revision of the R5RS that will
> expand its reach to include selected features of the
> R6RS. We are developing ERR5RS using a wiki hosted
> at the SchemePunks site:
>
> http://scheme-punks.cyber-rush.org/wiki/index.php?title=ERR5RS:Charter
Very good!
> Finally, ERR5RS will show respect for Scheme's tradition
> by preserving backward compatibility unless there is
> substantial agreement that today's and tomorrow's new
> requirements require some of yesterday's code or books
> or research papers to be rewritten or abandoned.
First question: what will you do about case sensitivity? There are very good
technical arguments to go with case-INsensitivity, due to casing problems in
unicode, and the ease of FFI with arbitrary machine code.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
William D Clinger
> First question: what will you do about case sensitivity? There are very good
> technical arguments to go with case-INsensitivity, due to casing problems in
> unicode, and the ease of FFI with arbitrary machine code.
Second question: Did you really mean "case-INsensitivity"?
The Unicode standard defines locale-independent case folding
(which the R6RS string-foldcase procedure implements), so
I don't know what those casing problems might be, but most
people who refer to such problems seem to be arguing for
case-sensitivity, and it seems to me that case-sensitivity
is often simpler than case-insensitivity when interfacing to
arbitrary external libraries.
As for our current thinking on this issue, see
http://scheme-punks.org/wiki/index.php?title=ERR5RS:Lexical_Syntax
You may want to list some technical arguments on the
discussion link from that page.
Will
Ray Blaak
> > First question: what will you do about case sensitivity? There are very good
> > technical arguments to go with case-INsensitivity, due to casing problems in
> > unicode, and the ease of FFI with arbitrary machine code.
>
> Second question: Did you really mean "case-INsensitivity"?
D'oh! But of course.
> The Unicode standard defines locale-independent case folding
> (which the R6RS string-foldcase procedure implements), so
> I don't know what those casing problems might be, but most
> people who refer to such problems seem to be arguing for
> case-sensitivity, and it seems to me that case-sensitivity
> is often simpler than case-insensitivity when interfacing to
> arbitrary external libraries.
Well yes. So this is a significant compatability impact.
I think it is worth it become case sensitive, myself.
>
> As for our current thinking on this issue, see
>
> http://scheme-punks.org/wiki/index.php?title=ERR5RS:Lexical_Syntax
>
> You may want to list some technical arguments on the
> discussion link from that page.
I will check it out and see if there is anything useful for me to add.
Ray Blaak
> Ray Blaak wrote:
>
> > First question: what will you do about case sensitivity? There are very good
> > technical arguments to go with case-INsensitivity, due to casing problems in
> > unicode, and the ease of FFI with arbitrary machine code.
>
> case-INsensitivity of Scheme symbols?
Not much. That was a brain fart on my part. I meant to say case-sensitive.
Brian Harvey
>is often simpler than case-insensitivity when interfacing to
>arbitrary external libraries.
As you know, I'm for case-insensitivity, partly for pedagogic reasons and
partly because I hate reading other people's code in which Foo and foo and
FOO and fOo all mean different things.
But I won't be too miserable if there's a #!r5rs feature that eliminates
everything incompatible with R5RS. I have to be able to include it in a
startup file and it has to still be in effect when Scheme is no longer in the
startup file but in the user-interactive REPL.
Brad Lucier
I first read the name of the project as ERRORS; I hope that's not a
premonition.
Brad
Harold Ancell
This is entirely deliberate, see
http://scheme-punks.org/wiki/index.php?title=ERR5RS:Acronym
or http://tinyurl.com/25kqbe for where errors might be....
I'm particularly pleased with its evocation of Boeing (Extended
Range) plus it being dead simple to remember and spell correctly.
- Harold
Ray Blaak
> > Second question: Did you really mean "case-INsensitivity"?
>
> D'oh! But of course.
Shit. D'oh! But of course not. case-SENsitivity.