Implementors' intentions concerning R6RS - comp.lang.scheme

Message from discussion Implementors' intentions concerning R6RS

fee...@iro.umontreal.ca

View profile

More options Oct 26 2007, 1:05 pm

Newsgroups: comp.lang.scheme

From: fee...@IRO.UMontreal.ca

Date: Fri, 26 Oct 2007 17:05:03 -0000

Local: Fri, Oct 26 2007 1:05 pm

Subject: Implementors' intentions concerning R6RS

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

At the Scheme workshop a few weeks ago there was a panel
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.

----------------------------------------------------------

Reply to author Forward