Implementors' intentions concerning R6RS
fee...@iro.umontreal.ca
discussion on the R6RS ("Discussion related to R6RS").
Mitch Wand, Mike Sperber and Aziz Ghuloum were on the panel.
The panelists expressed their opinion on the future adoption
of the R6RS by the Scheme community. An interesting
question was raised during the discussion period: "What are
the plans of the major Scheme implementors concerning the
adoption of the R6RS in their Scheme system?". Only the
implementors of PLT Scheme, Scheme 48 and Gambit were
present to answer. Matthew Flatt indicated that PLT Scheme
would be R6RS compliant in roughly 6 months. Mike Sperber
indicated that Scheme 48 would also comply with the R6RS in
the not too distant future. I mentionned that for Gambit
there are no plans to support the R6RS.
To arrive at a more detailed answer I have conducted a
survey covering several Scheme implementations. For each
implementation I solicited a short statement of intent from
the main implementor. The relevant information is
reproduced below. If you are an implementor and your
position is not included in the list, it would be
interesting to get your position by replying to
this thread on the R6RS mailing list with a brief
statement of intent.
It seems clear to me that few Scheme implementors have the
intention to modify their implementation to support R6RS
fully. Generally each implementor intends to pick and choose
minor R6RS features that will be supported (but not the same
set of features for all Scheme implementations). For this
reason I believe that R6RS will fail to achieve its goal of
allowing the sharing of code between different Scheme
subcommunities. We need to start working on a standard that
will.
Marc
--- Bigloo -----------------------------------------------
Manuel Serrano wrote:
There is no general plan to extend Bigloo to conform R6RS. I
might consider adding extensions that are compatible with
the current development of Bigloo (some R6RS naming
conventions and some cleanup of the libraries) but it is
highly unlikely that I will once consider deeper changes in
Bigloo for getting closer to R6RS.
--- Chicken ----------------------------------------------
Felix Winkelmann wrote:
There will be no action whatsoever to make the core CHICKEN
system R6RS compliant, neither will I implement new features
or modify existing ones with the intent of making our Scheme
more R6RS compatible (I speak for myself here -
co-developers may have other plans, and I can not and will
not try to prevent anybody from writing extensions that
bring R6RS functionality to CHICKEN).
R6RS must die.
--- Gambit -----------------------------------------------
Marc Feeley wrote:
There are no plans to extend Gambit to conform to the R6RS.
However some minor features will be supported (e.g. naming
convention for some fixnum and flonum operations, expression
comments, case sensitivity).
--- Gauche -----------------------------------------------
Shiro Kawai wrote:
I have no plan to make Gauche conform R6RS in any near
future, although I do plan to port most of useful features
in R6RS libraries and also optionally support R6RS module
syntax for the compatibility (that is, you will be able to
load R6RS library into Gauche, but Gauche's other parts
remain as they are). I do plan to fit Gauche to ERR5RS.
--- Guile ------------------------------------------------
Ludovic Courtes wrote:
I cannot speak for all GNU Guile developers. Nevertheless,
it appears to be unlikely that Guile will support R6RS
anytime soon given that (i) we probably lack the resources
to work on it and (ii) current developers don't seem to be
interested in it (I, for one, do not consider it a high
priority). We do have an implementation of a couple of R6RS
libraries, though (bytevectors and corresponding binary I/O
primitives), and there might eventually be others, depending
on demand.
--- JScheme ----------------------------------------------
Tim Hickey wrote:
There are no plans to make JScheme R6RS compliant. It
currently meets much of the R4RS standard but only
implements escape continuations (trycatch style) and
immutable strings (no string-set!) JScheme's raison d'etre
has been to allow Scheme-style programming with easy access
to the Java libraries. We may add some R6RS (and/or ERR5RS)
features to JScheme, time-permitting, and may add an R6RS
emulator. JScheme is open-source though so anyone who wants
to can make an R6RS compliant fork!
--- Kawa -------------------------------------------------
Per Bothner wrote:
I don't expect Kawa to be anywhere close to R6RS-compatible
anytime soon, partly due to limited time to work on it.
(There are other Kawa features that are higher priority to
me.) I expect Kawa may get pieces of R6RS as there is
demand and time. This is not a rejection of R6RS in
principle, since Kawa's compilation model is philosophically
in tune with R6RS (though Kawa of course also does have a
top-level eval scope), but a fact of limited resources
(which you can say is a rejection due to R6RS's size).
--- Larceny ----------------------------------------------
Will Clinger wrote:
The implementors of Larceny wish to support all relevant
standards for Scheme. Larceny currently implements the
ANSI/IEEE standard and the R5RS, with support for Snow. The
next public release of Larceny, planned for 1 November, will
support ERR5RS and will also provide an R6RS-compatible mode
of execution.
If the R6RS becomes a relevant standard, then Larceny will
eventually add an R6RS-conforming mode that uses a slow
interpreter to detect non-portable code in R6RS-style
programs. Larceny's R6RS-compatible but not R6RS-conforming
mode would continue to be the preferred mode for executing
R6RS programs.
--- Pika Scheme ------------------------------------------
Tom Lord wrote:
Scheme is relevance-challenged in its practical realization
yet in many ways front-and-center in terms of widespread
relevance of the basic ideas of Scheme. I'm not sure
statements of intent can change that. Nevertheless, I am
working on two implementations at the moment, both of which
have absolutely nothing to do with R6. If I succeed to the
extent of my wildest ideals, my efforts will result in many
forks and emulations, leading to a bushy little jumble of
Schemes, some of which have a lot of practical value -- and
then the question of language standards will be much more
immediately meaningful.
--- SCM and SLIB -----------------------------------------
Aubrey Jaffer wrote:
SCM
SCM's development is ongoing; there are no plans for SCM to
support R6RS beyond what R6RS features are provided by SLIB.
SLIB
SLIB's development is ongoing. For SLIB there are two
R6RS issues:
* Providing R6RS feature modules to R4RS and R5RS
implementations:
SLIB will continue to support R4RS and R5RS implementations.
Modules implementing R6RS features can be submitted for
inclusion into SLIB (where that is technically feasible).
* Using SLIB from R6RS implementations:
As of SLIB-3a3 (2006-02), SLIB's identifiers are safe for
case-sensitive implementations.
Because SLIB supports reflection as to imports and exports
from its modules, a program could be written which would
rewrite (most) SLIB modules into R6RS-libraries
(R6RS-libraries for other SLIB modules could be written
separately). All that would be needed is a volunteer.
--- SISC -------------------------------------------------
Scott G. Miller wrote:
Regarding SISC: We're still evaluating R6RS, but my initial
feeling is that we will support some but not all of R6RS.
We will support portability efforts around the module system,
syntax, etc. (In particular, I'm fairly certain we will
support ERR5RS if it is better received than R6RS). And
we're likely to adopt the Unicode portions if there is a
consensus among implementors.
--- Stalin and Scheme->C ---------------------------------
Jeffrey Mark Siskind wrote:
Here is my brief statement regarding Stalin.
I have no plans to update Stalin to support R6RS or any of
its distinctive features. I do not have the desire or the
resources needed to do so. Stalin is released under the GPL
so anyone else who wishes to take on such an effort is
welcome to do so.
And here is my brief statement regarding Scheme->C.
While I am not the author of Scheme->C (Joel Bartlett is), I
have been unofficially maintaining, porting, and packaging
Scheme->C for the past 16 years. I have no plans to update
Scheme->C to support R6RS or any of its distinctive
features. I do not have the desire or the resources needed
to do so.
--- STklos -----------------------------------------------
Erick Gallesio wrote:
I have no intent to support R6RS in the future. I'm really
not found of this version of the report. For me, Scheme
original spirit is completely lost with this iteration of
the report.
Of course, I will do my best to avoid unnecessary
incompatibilities in the new features I will add to STklos
in the future, but I'll definitively not take the R6RS as a
my development roadmap.
----------------------------------------------------------
Xah Lee
Thank you for this report.
Xah
x...@xahlee.org
http://xahlee.org/
Marc
[200 more lines on each Scheme implementor's positions]
...
namekuseijin
> Matthew Flatt indicated that PLT Scheme
> would be R6RS compliant in roughly 6 months.
no surprise since R6RS could be called R1RPLTS.
Still, it seems most of the responses were driven by not enough
developer resources or by implementations which don't already have a
working module system...
> For this
> reason I believe that R6RS will fail to achieve its goal of
> allowing the sharing of code between different Scheme
> subcommunities.
Has any RNRS so far allowed for the sharing of non-trivial code
between different Scheme subcommunities?
Perhaps rather than searching for a new standard we should search for
cooperation between developers of Scheme implementations? i.e: less
implementations, more-robust, standard-compliant ones with a wealth of
extensions in the form of truly shareable and possibly compilable
scheme modules?...
ruhe...@mac.com
To summarize, the developers of PLT Scheme and Scheme 48 expressed a
commitment to support R6RS fully. And Will Clinger, somewhat
reluctantly it seems, expressed a willingness to go make Larceny
"compatible" with R6RS. That is, only 3 of the 13 implementations
surveyed have expressed a commitment to support R6RS, or at least
become compatiable with R6RS.
What about Chez Scheme, one of the few commercial implementations?
Kent Dybvig was one of the editors of R6RS, of course.
I don't want to try to put a positive spin on this disappointing, but
not, surprising result. However, I wonder if another survery wouldn't
be more relevant for predicting R6RS's future. How many developers of
libraries are planning to port their libraries to R6RS, or develop new
libraries for R6RS?
I'd also be interested in some statistics about the size of the user
communities of the various implmentations surveyed. If PLT Scheme for
example already has, say, a 80% share of the market, then the
commitment of other implemenations to R6RS may not be especially
relevant for estimating its chance of succeeding.
- Tom Gordon
Graham Fawcett
> communities of the various implmentations surveyed. If PLT Scheme for
> example already has, say, a 80% share of the market, then the
> commitment of other implemenations to R6RS may not be especially
> relevant for estimating its chance of succeeding.
That would make sense if Scheme were a product, and the Scheme
community was a competitive market. Since they aren't, it smells like
pro-R6RS rationalization.
Clearly the R6RS process has had, for better or worse, a fracturing
effect on the Scheme community. Perhaps the fracture line has simply
formed between the PLT/commercial bloc and "everyone else".
G
samth
This is not true. What happened was that R6RS *exposed* a pre-
existing
fracture in the Scheme community. The fracture has been there a long
time, and can be seen even in the controversies over R5RS.
sam th
namekuseijin
> This is not true. What happened was that R6RS *exposed* a pre-
> existing
> fracture in the Scheme community. The fracture has been there a long
> time, and can be seen even in the controversies over R5RS.
indeed. It's the fracture between academics wanting a small Scheme
geared at education and research and ex-students who grew on Scheme
and now want it to be a real tool for real world projects, rather than
embracing the old horse Common Lisp.
Anton van Straaten
The problem with this characterization is that many academics want a
more relevant Scheme for both education and research. More relevant
inevitably means larger, because there are many features which R5RS
lacks which are important for education and research.
At the level of a CS 101 course, a language as small or smaller than
R5RS may be useful. But at that level, it's easy and common enough to
teach a subset of a language. Aside from basic intro courses, who's
using anything close to R5RS Scheme in education or research these days?
If there is anyone, how do they handle basic issues like defining new
data types?
Besides, the strongest argument against the idea that the fractures in
the community are mainly about size vs. pragmatism are Scheme
implementations themselves. Which widely-used Scheme implementations
are "small"? Which ones ignore pragmatic concerns in the interests of
remaining small?
Anton
William D Clinger
> This is not true. What happened was that R6RS *exposed* a
> has been there a long time, and can be seen even in the
> controversies over R5RS.
What the R6RS exposed was the conflict between those who
think the technical quality of a language's design and
specification actually matters, and those who think the
primary purpose of a language standard is to convince
funding agencies and prospective users that the language
community has its act together.
Thanks to the low threshold for ratification of R6RS, the
cynical faction won the day. In the past, however, Scheme
has been noted for its claims to technical quality. It
remains to be seen whether Scheme's brand image can survive
its most recent marketing success.
Will
Ray Dillinger
> What the R6RS exposed was the conflict between those who
> think the technical quality of a language's design and
> specification actually matters, and those who think the
> primary purpose of a language standard is to convince
> funding agencies and prospective users that the language
> community has its act together.
Just looking in today. This thread (particularly the good
news that most implementors are rejecting R6RS out-of-hand
as a Bad Idea) gives me hope that the newsgroup may continue
to be relevant to my interests in Scheme.
R6RS made me angry. It had bad semantics, failed to abstract
anything to the point where alternatives could be implemented
or even discussed, and such extensions as there were, were
ham-handed, mostly blind copying from other languages or current
ephemera, and did not take advantage of Scheme's existing
structure. Instead of clarifying and abstracting the language
away from its libraries, the language has been muddied with
concepts arising from mere current ephemera creeping into the
language core in order to accomodate so-called libraries that
cannot be separated from the language core at all.
Going with "language and libraries" was a good idea, and the
module system adopted for R6RS doesn't suck as hard as some
of the alternatives. But the division between language and
libraries was not carried out at a level that allows any
alternatives to the specified libraries to be linked in. If,
for example, you want to use a different character set: You
can't just write and link your own read, your own write, your
own string and character manipulation routines, etc, to replace
the extant character library; R6RS failed to abstract these
things to the point where an alternative was possible. The
character library isn't even a separate entity from the other
libraries, much less one with a specified and usable interface.
That was the failure. All these so-called "relevant" ephemera
could have been implemented as real (and replaceable)
libraries, leaving room for experimentation with alternatives,
adaptation to machines with fundamentally different
representation capabilities, or growth.
Scheme could have remained a simple, elegant language for
processing information even with all these bells and whistles
added, had the committee taken the time and care to properly
separate the vision of the language (an eternal and perfect
substrate for manipulating abstract information) from the
grotty day-to-day crapwork of the libraries (ephemera for
dealing with particular character sets, representations,
computers and binary APIs, none of which will be relevant
a thousand years from now).
The failure to do the separation properly was the R6RS committee
reneging on a promise. It did not, after all, extract that
eternal substrate for manipulating abstract information and
define proper connections between it and other things; instead
it buried the jewel under a mountain of mud where it can no
longer be seen, accessed, or used without getting mud all over
you.
In my opinion: if something isn't the Right Thing, or if you
suspect that in a thousand years from now it may not STILL be
the Right Thing, then it doesn't belong in the Scheme language
standard. If it's for dealing with anything less permanent
than pi, phi, the pyramids or the parthenon, then by all means
do it, but put it into a library and make sure that the library
really *IS* separable from the language (and from the other
libraries, insofar as possible) and make sure that the language
gives you the capabilities to implement and use alternatives
to that library.
Bear
Tom Lord
> Thanks to the low threshold for ratification of R6RS, the
> cynical faction won the day. In the past, however, Scheme
> has been noted for its claims to technical quality. It
> remains to be seen whether Scheme's brand image can survive
> its most recent marketing success.
>
Hi. Nice to meet ya'.
I kinda want to say (in a friendly, well-meant
way): "grow a pair" and "suck it up". But
I don't mean that at all cynically -- not much
anyway. The cure for R6 is in the future:
>From here on out, post R6 and ERR5, let's all
agree to this: Scheme should evolve by subsumption,
not evolution.
And, from here on out, deep capability improvements
are the purpose of the R_ series, while broad
capability improvements are SRFIs.
May I unpack that for you?:
We must cool the core. Two qualitative aspects
of a "core Scheme" are its primitiveness (its
support for the broadest possible range of programming
paradigms) and its complexity. If we imagine
quantifying these: The higher the "primitiveness"
metric, the less primitive a core is. The lower
the "complexity" metric, the less complex the core
is. RnRS could have a "heat" which is an ordered
pair (Primitiveness_n, Complexity_n). From here on
out, the R_ series must have a monotonically
decreasing "heat". Mmmm 'k? That's what I mean
by "subsumption" -- each new improvement will
find a simpler and/or more general superstructure
in which the previous standard is reduced to just a
particular assemblage of parts.
I'm exteremely confident that the core ideas shared
among Scheme enthusiasts are amply powerful that
R6 can be subsumed. What you are doing with Larceny
just about counts as a proof: R6 is, to you, a
library. Well, we ought to find and work on
standardizing ways in which R6 can be merely a
library to everyone, in a portable way. (Note:
I'm using "library" broadly here -- I know you
are, for example, compiler hacking.)
Meanwhile, there is the nagging question of
"broad functionality". All those lesser languages
tend to have much more ample libraries and there's
only so far one would want to try to go with
cheerleading volunteers to crank more and more
of those for Scheme. Well... SRFIs are a decent
bureaucratic infrastucture for breadth. I think
our real problem is content focus.
Plug your nose. Ready? The Scheme community
isn't 1/100th as interested in the web as it ought
to be if Scheme is going anywhere.
Examples: every single other mod language out there
is fairly agressively chasing the promise of a
common VM, ideally something that will converge
with standard web client and server vms like
javascript and jvm. Scheme is underpresented in
these discussions, badly.
Every single other language modern language out
there is agressively adding better and better SAX
and DOM support and standard processors like XSLT
and XQuery. The better ones are well off towards
working on persistence. Scheme is way too tentative
in these areas (and Cowan's work on R6 is a
HUGE gift towards fixing that, my objections
notwithstanding).
I am at the point, lately, where I find myself
daydreaming about the possibility of a Scheme
that even does away with CONS pairs and VECTORS
in favors of XML trees.... (Actually, I built
and released that, though few have noticed yet. :-)
All that said, it's very, very hard to pick
smart moves for something abstract like a language
without actual demand driving the problem.
It's all well and good for me to say we really need
lots of web foo, for example, but its pretty
useless unless there's demand for labor to work
on such problems.
We can sketch stuff all day....
-t
Tom Lord
a future R_ series that monotonically
decreases in primitiveness x complexity:
This program is not only within the spirit
of Scheme but it also will dissolve Scheme
until there is naught but SRFIs. More than
one "basis set" -- more than one equally
good those differently emphatic cores can
be identified, I'm sure we're all certain.
What should eventually form is simply a
lattice of features with, near the bottom,
a formal, rigorous, and robust explication
of the essence of various practical strategies
for interpretation.
So there.
-t
Benedikt Rosenau
[...]
> indeed. It's the fracture between academics wanting a small Scheme
> geared at education and research and ex-students who grew on Scheme
> and now want it to be a real tool for real world projects, rather than
> embracing the old horse Common Lisp.
Not so. PLT-Scheme is not the only big or useful implementation there
is. If anything, I see a connection between the implementations I
consider useful for real world applications and the rejection of the
standard by the implementors.
Benedikt