What's Scheme reference point?
Slobodan Blazeski
(*) preferably regarding R6RS, describing functionality integrated in
the language.
cheers
Slobodan
Pascal J. Bourguignon
> What Schemers use as a reference point? Something akin cl's hyperspec
> (*) preferably regarding R6RS, describing functionality integrated in
> the language.
http://www.schemers.org/ gathers a lot of scheme documentation and
references, including:
http://www.schemers.org/Documents/Standards/R5RS/
On the other hand, R6RS has its own site: http://www.r6rs.org/
(but I'd stay with R5RS, and wait for R7RS).
--
__Pascal Bourguignon__
Grant Rettke
wrote:
> What Schemers use as a reference point? Something akin cl's hyperspec
> (*) preferably regarding R6RS, describing functionality integrated in
> the language.
Aaron W. Hsu
<slobodan...@gmail.com> wrote:
> What Schemers use as a reference point? Something akin cl's hyperspec
> (*) preferably regarding R6RS, describing functionality integrated in
> the language.
If I am doing language semantics lawyering, I use the R6RS PDF. If I am
just programming, I use "The Scheme Programming Language" 4th ed. that is
available online [1]. I then use the reference manual for each of the
libraries I use, and the manual of my Scheme implementation [2].
[1] <http://www.scheme.com/tspl4/>
[2] <http://www.scheme.com/csug8/>
Aaron W. Hsu
--
Of all tyrannies, a tyranny sincerely exercised for the good of its
victims may be the most oppressive. -- C. S. Lewis
Slobodan Blazeski
wrote:
> Slobodan Blazeski <slobodan.blaze...@gmail.com> writes:
> > What Schemers use as a reference point? Something akin cl's hyperspec
> > (*) preferably regarding R6RS, describing functionality integrated in
> > the language.
>
> references, including:http://www.schemers.org/Documents/Standards/R5RS/
>
> On the other hand, R6RS has its own site:http://www.r6rs.org/
> (but I'd stay with R5RS, and wait for R7RS).
>
> --
> __Pascal Bourguignon__
Andrew Reilly
> What Schemers use as a reference point? Something akin cl's hyperspec
> (*) preferably regarding R6RS, describing functionality integrated in
> the language.
Until fairly recently, the "official" spec r5rs was small enough that
every practical scheme implementation was practically its own thing, even
when compatibility with the standard was claimed. The supplied
documentation for most implementations would contain or refer to the r5rs
standard document and then describe the local differences and
extensions. Sometimes this would simply be a listing of which SRFIs were
supported (http://srfi.schemers.org/final-srfis.html), sometimes more or
different.
Now there's r6rs (at http://www.r6rs.org/) which has a somewhat useful
standard library, but nothing as extensive as the libraries that come
with the big implementations, so the situation has not changed
dramatically.
Personally, I'm more or less happy to keep just using PLT's scheme (which
is neither r5rs nor r6rs, completely), and has extensive built-in and on-
line documentation. (http://doc.plt-scheme.org/) This also has the full
text of both the r5rs, r6rs and a fair chunk of the SRFIs, and has a cool
javascript-powered search function. I reckon it's as good a place to
start as any.
Cheers,
--
Andrew
Benjamin L. Russell
wrote:
>Personally, I'm more or less happy to keep just using PLT's scheme (which
>is neither r5rs nor r6rs, completely), and has extensive built-in and on-
>line documentation. (http://doc.plt-scheme.org/) This also has the full
>text of both the r5rs, r6rs and a fair chunk of the SRFIs, and has a cool
>javascript-powered search function. I reckon it's as good a place to
>start as any.
Another implementation is Chez Scheme [1] (see
http://www.scheme.com/). The fourth edition of _The Scheme
Programming Language_ [2], available online (see
http://www.scheme.com/tspl4/), uses that implementation and is also
referenced on that site, as does the _Chez Scheme Version 7 User's
Guide_ [3] (see http://www.scheme.com/csug7/). Although the fourth
edition is R6RS-compliant, you can still read the R5RS-compliant third
edition [4] online (see http://www.scheme.com/tspl3/).
One R5RS Scheme implementation that I enjoy using is Gauche Scheme [5]
(see http://practical-scheme.net/gauche/) with extensions. It is
useful as a scripting language, integrates well with Emacs, and
provides good Unicode support (I live in a foreign country (Japan)
where the dominant written language uses a two-byte character set that
cannot be fully expressed in ASCII--hence Unicode support is important
in this case). The _Gauche Users' Reference_ [6] is available online
(see http://practical-scheme.net/gauche/man/gauche-refe.html).
If you use Windows, Gauchebox-0.8.14-box1.exe [7] (available at
http://sourceforge.net/projects/gauche/files/) is a convenient Windows
installer for Gauche Box, the Gauche version of Lispbox, and bundles
Gauche with GNU Emacs. Since the Gauche Box version, unlike the
source code version, does not include all the system functions, you
can then separately download and install Cygwin [8] (see
http://www.cygwin.com/), compile Gauche separately from source code on
Cygwin, and then reconfigure Gauche Box to work with the Cygwin
version; you will then have access to all the system functions.
Just because an implementation has many libraries and a convenient
user interface does not necessarily mean that it is fast, particularly
when running programs making extensive use of the "eval" function
(which, granted, may not be relevant unless you use the "eval"
function extensively). While I cannot vouch for their accuracy or
relevance (different implementations tend to have different advantages
and disadvantages, and must be evaluated in their full context, rather
than just with respect to a benchmark), just for reference, you may
also wish to take a look at a benchmark test comparing the speed of
"eval" running on thirteen different Scheme, Lisp, and Lisp-like
dialects/implementations at the following site [9]:
"Kazimir Majorinc's Programming Notes.: Speed of Newlisp Eval Test:
v10.0. Slightly but Significantly Faster Than v. 9.3."
http://kazimirmajorinc.blogspot.com/2008/12/speed-of-newlisp-eval-test-v100.html
Of additional interest is the following (admittedly outdated) thread,
which addresses the issues of space leaks in implementating promises
using the call/cc function in Petite Chez Scheme vs. MzScheme [10]:
Delay, force and tail recursion - comp.lang.scheme
http://groups.google.com/group/comp.lang.scheme/browse_thread/thread/8bbed864094990e/8fda18c6d0f7f5bd?lnk=gst&q=Chez#8fda18c6d0f7f5bd
Furthermore, before taking a stand on R5RS vs. R6RS, you may wish to
read the "Scheme Steering Committee Position Statement" [11] (see
http://scheme-reports.org/2009/position-statement.html): The split
between the two has become significantly great that the committee is
moving toward two separate versions of Scheme for R7RS, to be called
"small" and "large" Scheme:
>Small Scheme
>
> * Constituencies: educators, casual implementors, researchers, embedded languages, "50-page" purists
> * Think "IEEE/R5RS brought up to the current date."
> * ~ 90% supermajority to be required for final ratification
>
>Large Scheme
>
> * Constituencies: programmers, implementors
> * Think "R6RS with a happier outcome."
> * ~ 75% supermajority to be required for final ratification
On Mon, 9 Nov 2009 14:05:54 -0800 (PST), Slobodan Blazeski
<slobodan...@gmail.com> wrote:
>> On the other hand, R6RS has its own site:http://www.r6rs.org/
>> (but I'd stay with R5RS, and wait for R7RS).
>A bird in the hand is worth two in the bush
Indeed; but once the species becomes extinct, it can't prosper, can
it?
-- Benjamin L. Russell
[1] Cadence Research Systems. "(chez (chez scheme))." 27 Aug. 2009. 10
Nov. 2009. <http://www.scheme.com/>.
[2] Dybvig, R. Kent. _The Scheme Programming Language, Fourth
Edition._ Cambridge, MA: The MIT Press, 2009.
<http://www.scheme.com/tspl4/>.
[3] Dybvig, R. Kent. _Chez Scheme Version 7 User's Guide._ R. Kent
Dybvig, 2005. <http://www.scheme.com/csug7/>.
[4] Dybvig, R. Kent. _The Scheme Programming Language, Third Edition._
Cambridge, MA: The MIT Press, 2003. <http://www.scheme.com/tspl3/>.
[5] Kawai, Shiro. "Gauche - A Scheme Interpreter." 7 Oct. 2008. 10
Nov. 2009. <http://practical-scheme.net/gauche/>.
[6] Kawai, Shiro. "Gauche Users' Reference." 7 Oct. 2008. 10 Nov.
2009. <http://practical-scheme.net/gauche/man/gauche-refe.html>.
[7] Kawai, Shiro. "Browse Gauche Files on SourceForge.net." 11 Nov.
2008. 10 Nov. 2009. <http://sourceforge.net/projects/gauche/files/>.
[8] Red Hat, Inc. "Cygwin Information and Installation." 10 Nov. 2009.
10 Nov. 2009. <http://www.cygwin.com/>.
[9] Majorinc, Kazimir. "Kazimir Majorinc's Programming Notes.: Speed
of Newlisp Eval Test: v10.0. Slightly but Significantly Faster Than v.
9.3." Online posting. Dec. 2008. 10 Nov. 2009.
<http://kazimirmajorinc.blogspot.com/2008/12/speed-of-newlisp-eval-test-v100.html>.
[10] Andre. "Delay, force and tail recursion." Online posting. 28 Aug.
2003. 10 Nov. 2009. <news://comp.lang.scheme>. Also
available at
<http://groups.google.com/group/comp.lang.scheme/msg/8fda18c6d0f7f5bd>.
[11] Scheme Steering Committee. "Scheme Steering Committee Position
Statement." 20 Aug. 2009. 10 Nov. 2009.
<http://scheme-reports.org/2009/position-statement.html>.
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Slobodan Blazeski
wrote:
> On Mon, 9 Nov 2009 14:05:54 -0800 (PST), Slobodan Blazeski
>
> >> On the other hand, R6RS has its own site:http://www.r6rs.org/
> >> (but I'd stay with R5RS, and wait for R7RS).
> >A bird in the hand is worth two in the bush
>
> Indeed; but once the species becomes extinct, it can't prosper, can
> it?
implying something else?
Slobodan Blazeski
> On Mon, 09 Nov 2009 06:52:19 -0800, Slobodan Blazeski wrote:
> > What Schemers use as a reference point? Something akin cl's hyperspec
> > (*) preferably regarding R6RS, describing functionality integrated in
> > the language.
>
> Until fairly recently, the "official" spec r5rs was small enough that
> every practical scheme implementation was practically its own thing, even
> when compatibility with the standard was claimed.
> Now there's r6rs (athttp://www.r6rs.org/) which has a somewhat useful
> standard library, but nothing as extensive as the libraries that come
> with the big implementations, so the situation has not changed
> dramatically.
It happens everywhere, except perhaps Visual Studio which is a story
for itself. In the project I work we had to switch from Netbeans to
Eclispe because a major library worked only on Eclipse. So I I can
live with it.
Slobodan Blazeski
http://slobodanblazeski.blogspot.com/
Aaron W. Hsu
<DekuDe...@yahoo.com> wrote:
> Another implementation is Chez Scheme [1] (see
> http://www.scheme.com/). The fourth edition of _The Scheme
> Programming Language_ [2], available online (see
> http://www.scheme.com/tspl4/), uses that implementation and is also
> referenced on that site, as does the _Chez Scheme Version 7 User's
> Guide_ [3] (see http://www.scheme.com/csug7/). Although the fourth
> edition is R6RS-compliant, you can still read the R5RS-compliant third
> edition [4] online (see http://www.scheme.com/tspl3/).
Just to clarify, "The Scheme Programming Language" is not implementation
specific, and details the Scheme language as written in the standards.
Specifically, the third edition focuses on the R5RS report, and the fourth
edition on the R6RS standard. They are however, written by R. Kent Dybvig,
who writes Chez Scheme. Chez Scheme's specific extensions are documented
in the "Chez Scheme User's Guide," versions 7 and 8, with 8 being the
associated guide to the upcoming version 8 that will support R6RS (a
pre-release is available now).
> Just because an implementation has many libraries and a convenient
> user interface does not necessarily mean that it is fast, particularly
> when running programs making extensive use of the "eval" function
> (which, granted, may not be relevant unless you use the "eval"
> function extensively). While I cannot vouch for their accuracy or
> relevance (different implementations tend to have different advantages
> and disadvantages, and must be evaluated in their full context, rather
> than just with respect to a benchmark), just for reference, you may
> also wish to take a look at a benchmark test comparing the speed of
> "eval" running on thirteen different Scheme, Lisp, and Lisp-like
> dialects/implementations at the following site [9]:
Indeed, one of the major advantages of Scheme is that the multiple
implementations allows an user to select an implementation closely suited
to his or her needs. This has obvious problems of course, but nonetheless
makes it possible to get a Scheme tailored to your needs.
> Furthermore, before taking a stand on R5RS vs. R6RS, you may wish to
> read the "Scheme Steering Committee Position Statement" [11] (see
> http://scheme-reports.org/2009/position-statement.html): The split
> between the two has become significantly great that the committee is
> moving toward two separate versions of Scheme for R7RS, to be called
> "small" and "large" Scheme:
It should be emphasized that this is an attempt to reorganize the split
into a cohesive, compatible division, rather than an incompatible battle
front. The goals of the committee as I read them are not to foster a fork
of Scheme into two separate or different languages, but to separate out
the specification of the Scheme language into two parts so that the two
camps can cooperate with better clarity.
Aaron W. Hsu
<slobodan...@gmail.com> wrote:
> In the project I work we had to switch from Netbeans to
> Eclispe because a major library worked only on Eclipse. So I I can
> live with it.
Even though there are various incompatibilities among Schemes, the good
news is that moving code from one to the other is actually not too
difficult in most cases. There are certain things that take some more
work, but overall, if you have a Scheme that handles almost everything you
want except for this library or that, you can usually find a way to get it
over to your system, assuming it's not using some very specific
implementation level feature that is not implemented elsewhere.
Benjamin L. Russell
<slobodan...@gmail.com> wrote:
>On Nov 10, 9:12?am, Benjamin L. Russell <DekuDekup...@Yahoo.com>
>wrote:
>> On Mon, 9 Nov 2009 14:05:54 -0800 (PST), Slobodan Blazeski
>>
>> <slobodan.blaze...@gmail.com> wrote:
>> >> On the other hand, R6RS has its own site:http://www.r6rs.org/
>> >> (but I'd stay with R5RS, and wait for R7RS).
>> >A bird in the hand is worth two in the bush
>>
>> Indeed; but once the species becomes extinct, it can't prosper, can
>> it?
>I don't understand your remark. Is Scheme going extinct or you
>implying something else?
No intention to start another debate, but, well, I interpreted your "a
bird in the hand" as representing R6RS, and "two in the bush" as
representing R5RS and (the upcoming) R7RS, so I meant "R6RS" by "the
species," meaning that if R6RS becomes extinct, then it may not
necessarily be worth the "two in the bush" (R5RS and R7RS). However,
that assumes that it actually becomes extinct, which, granted, is
still open to question. At least some parts of R6RS are more likely
to survive in one form or another; the real question seems to be
whether the new official Scheme specification will return to one for a
simple language, continue to be one for larger language, or split into
two distinct specifications (currently the most likely outcome).
Alternatively, might you have meant "small Scheme" and "large Scheme"
of R7RS by "two in the bush?" Actually, that would make more sense,
since they are both still being specified.
One look at the members of the current Scheme Steering Committee [1]
(see http://scheme-reports.org/2009/announcement.html) will show that
R7RS is very likely to be quite different from spirit from R6RS:
Will Clinger
Marc Feeley
Chris Hanson
Jonathan Rees
Olin Shivers
According to "[r6rs-discuss] a politically incorrect guide to the
candidates" [2] (see
http://lists.r6rs.org/pipermail/r6rs-discuss/2009-February/003776.html),
>Turning to the implementors, Will Clinger is the only
>candidate who has implemented the R6RS. [Will Clinger
>actually voted against R6RS ratification, however (see
>"R6RS Ratification Vote" at
>http://www.r6rs.org/ratification/results.html).]
>
>[...]
>
>Marc Feeley polled implementors of the R3RS/R4RS/R5RS
>and IEEE/ANSI Scheme to gauge their enthusiasm for the
>draft R6RS that was put up for ratification; that was
>something the editors themselves should have done.
>Marc also served as the original chair of the R6RS
>editors' committee. [Marc Feeley also actually voted against ratification.]
>Chris Hanson, who has been maintaining MIT Scheme, is
>a charter author of the R*RS documents, and was an
>editor of the IEEE-1178 standard. He also wrote much
>of that standard's Appendixes B and C, which were
>significant milestones during the standardization of
>Scheme (and Lisp generally). [Chris Hanson voted against ratification, too.]
>
>Jonathan Rees was one of the original implementors of
>T and Scheme 48. He too is a charter author of the
>R*RS documents, and was editor of the much-beloved
>R3RS. [Jonathan Rees voted against ratification as well.]
>
>Olin Shivers is responsible for scsh. Among the
>twelve candidates, he is the only implementor who
>abstained from the R6RS ratification vote.
So none of the current members voted for R6RS ratification; all but
one voted against ratification, and one abstained.
Of course, the official specification doesn't matter if
implementations ignore it. But then again, isn't that what happened
with R6RS with such implementations as Gauche, Chicken, MIT/GNU
Scheme, Bigloo, Gambit, Guile, JScheme, Pika Scheme, SCM, Stalin,
Scheme->C, and STklos (see "Implementors' intentions concerning R6RS -
comp.lang.scheme" [3] at
http://groups.google.com/group/comp.lang.scheme/msg/e1a107ccd60810a3)?
Granted, on the other hand, Larceny, PLT Scheme, and Ypsilon provide
support for R6RS, Scheme 48 is scheduled to provide support in "the
not too distant future" (to quote the above post), Kawa may support
R6RS at some point in the future (depending on availability of
resources), SLIB may include modules implementing R6RS features
(barring technical feasibility), and SISC may support some but not all
of R6RS.
Perhaps the scale of this split is what prompted the current Steering
Committee to come up with the idea of a "small Scheme" vs. a "large
Scheme" (at least, to quote Aaron W. Hsu's response [4] in this
thread, as "an attempt to reorganize the split into a cohesive,
compatible division")?
-- Benjamin L. Russell
[1] Scheme Steering Committee. "New Steering Committee's
announcement." 21 Aug. 2009. 11 Nov. 2009.
<http://scheme-reports.org/2009/announcement.html>.
[2] Clinger, William D. "[r6rs-discuss] a politically incorrect guide
to the candidates." Online posting. 9 Feb. 2009. 11 Nov. 2009.
<http://lists.r6rs.org/pipermail/r6rs-discuss/2009-February/003776.html>.
[3] Feeley, Marc. "Implementors' intentions concerning R6RS -
comp.lang.scheme." Online posting. 27 Oct. 2007. 11 Nov. 2009.
<news://comp.lang.scheme>. Also available at
<http://groups.google.com/group/comp.lang.scheme/msg/e1a107ccd60810a3>.
[4] Hsu, Aaron W. "Re: What's Scheme reference point?" Online posting.
11 Nov. 2009. 11 Nov. 2009. <news://comp.lang.scheme>. Also available
at
<http://groups.google.com/group/comp.lang.scheme/msg/770897bd6694a15b>.
Benjamin L. Russell
<DekuDe...@Yahoo.com> wrote:
>Of course, the official specification doesn't matter if
>implementations ignore it. But then again, isn't that what happened
>with R6RS with such implementations as Gauche, Chicken, MIT/GNU
>Scheme, Bigloo, Gambit, Guile, JScheme, Pika Scheme, SCM, Stalin,
>Scheme->C, and STklos (see "Implementors' intentions concerning R6RS -
>comp.lang.scheme" [3] at
>http://groups.google.com/group/comp.lang.scheme/msg/e1a107ccd60810a3)?
>Granted, on the other hand, Larceny, PLT Scheme, and Ypsilon provide
>support for R6RS, Scheme 48 is scheduled to provide support in "the
>not too distant future" (to quote the above post), Kawa may support
>R6RS at some point in the future (depending on availability of
>resources), SLIB may include modules implementing R6RS features
>(barring technical feasibility), and SISC may support some but not all
>of R6RS.
Oops, I forgot to add Chez Scheme and Ikarus to the list of
implementations that do provide support for R6RS. For easier
reference, maybe I should create a list of Scheme implementations with
respect to current, future, or tentative R6RS support, or lack
thereof, as follows:
Scheme Implementations Not Scheduled to Provide R6RS Support:
Bigloo
Chicken
Gambit
Gauche
Guile
JScheme
LispMe (PalmOS Scheme implementation discontinued as of 8 Aug. 2008)
MIT/GNU Scheme
Pika Scheme
Scheme->C
SCM
Stalin
STklos
Scheme Implementations That May Provide R6RS Support in the Future:
Kawa
SISC
SLIB
Scheme Implementations Scheduled to Provide R6RS Support:
Scheme 48
IronScheme
Scheme Implementations Providing Full R6RS Support:
Chez Scheme
Ikarus
Larceny
PLT Scheme
Ypsilon
(I was very surprised to come across the above-mentioned LispMe (a
misnomer, since it is actually an implementation of Scheme)
programming language. I used to use a PalmOS-based PDA (a Handspring
Visor Deluxe (Ice)) (until it was stolen in Manhattan in circa
December of 2002); before purchasing a PowerBook, I used to want
desperately to program in Scheme on my PDA, but hadn't been aware of
LispMe [1] (see http://www.lispme.de/lispme/index_en.html). (The page
even references a comparison by Michael Winikoff [2] (see
http://www.aldweb.com/pages/winikoff/) to other PalmOS-based
programming languages.))
-- Benjamin L. Russell
[1] Bayer, Fred. "LispMe home page." Fred Bayer. 11 Aug. 2008. 11 Nov.
2009. <http://www.lispme.de/lispme/index_en.html>.
[2] Winikoff, Michael. "Palm: Software Development - Alternatives to
C." Michael Winikoff. 29 Oct. 2009. 11 Nov. 2009.
<http://www.aldweb.com/pages/winikoff/>.
Marco Maggi
> Oops, I forgot to add Chez Scheme and Ikarus to the list
> of implementations that do provide support for R6RS.
And Mosh.
--
Marco Maggi
Marco Maggi
> Scheme 48 is scheduled to provide support in "the not too
> distant future" (to quote the above post),
This statement is expired, no? ;-)
Am I mistaken in thinking that if an implementation has
no (at least partial) support for R6RS today, it will never
have it?
--
Marco Maggi
Benjamin L. Russell
wrote:
Not necessarily.
The problem in the case of some implementations is that R6RS is a much
larger specification than R5RS (approximately three times the number
of pages), and requires more resources to implement.
For example, Per Bothner writes [1] regarding Kawa (see
http://groups.google.com/group/comp.lang.scheme/msg/e1a107ccd60810a3)
as follows:
>I don't expect Kawa to be anywhere close to R6RS-compatible
>anytime soon, partly due to limited time to work on it....
>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).
In Kawa's case, the problem is with limited resources, not the
compilation model itself.
Furthermore, Tom Lord writes regarding Pika Scheme (see the
above-mentioned link) as follows:
>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.
In Pika Scheme's case, the issue is relevance: The R5RS vs. R6RS
debate is irrelevant to Tom Lord. Should it become relevant, Lord may
choose a stance, which may or may not involve (at least partial)
support for R6RS.
Of course, in some other cases, an issue of basic principle is
involved: For example, Erick Gallesio writes regarding STklos as
follows (see the same above-mentioned link):
>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.
In this case, the issue is one of basic principle, not resources;
thus, Gallesio's stance is unlikely to change in the near future.
-- Benjamin L. Russell
[1] Feeley, Marc. "Implementors' intentions concerning R6RS -
comp.lang.scheme." Online posting. 27 Oct. 2007. 11 Nov. 2009.
<news://comp.lang.scheme>. Also available at
<http://groups.google.com/group/comp.lang.scheme/msg/e1a107ccd60810a3>.
Slobodan Blazeski
wrote:
> On 9 Nov 2009 22:37:11 GMT, Andrew Reilly <areilly...@bigpond.net.au>
> wrote:
[snip]
> Furthermore, before taking a stand on R5RS vs. R6RS, you may wish to
> between the two has become significantly great that the committee is
> moving toward two separate versions of Scheme for R7RS, to be called
> "small" and "large" Scheme:
I guess its a fair goal, small core for the researchers and those with
specific constraints, large and portable for those concerned with
practical aspects. Anyway it will take years before R7RS is ready and
even more to have that large scheme implemented so for now I hope that
R6RS will do.
Grant Rettke
wrote:
> I hope that R6RS will do.
I will do fine.