[r6rs-discuss] Now, where were we?
Anton van Straaten
anton at appsolutions.com
Sun Feb 22 20:48:44 EST 2009
Brian Harvey wrote:
> Let me be clear that I don't want to make any claims about anyone else's
> state of mind, but /how it seems from here/, looking at the results, is
> that R6 was a huge move away from Lisp's roots as the language for
> experimentation. How can any Lisper feel that the REPL is just an
I think the idea that the REPL is an afterthought is the wrong
conclusion to draw from R6RS. Did one of the R6RS editors actually say
something to that effect? If you point me to such a claim, I'll be
happy to refute it definitively, if I haven't already done so below. ;)
One of the explicitly stated goals for R6RS was that of being able to
exchange Scheme source code in libraries that would work across
implementations. To do that successfully, the semantics of the language
need to be quite well-specified.
The REPL specification in R5RS is quite vague. R5RS describes the
possibility of REPLs, and sketches some possible semantics, rather than
defining the semantics of a specific REPL.
Fixing this vagueness is arguably of dubious value - is it necessary
that every Scheme's REPL behave the same?
Even just developing a specification for "top-level programs" and
"scripts" - in order to have some portable way of invoking portable
libraries - involved a fair amount of editorial effort. The "scripts"
specification was relegated to the Non-Normative Appendices largely
because it was not as fully developed as the editors would have liked.
In some alternate universes that we almost ended up living in, R6RS
might have been finalized with nothing more than a way to specify
libraries. Or perhaps we are in fact in such a universe, as some have
argued, given the immaturity of the top-level programs and scripts
If we were to acknowledge some version of this reality, and rename R6RS
to "The Unrevised Specification for the Definition and Use of Scheme
Libraries", then a REPL specification might actually be considered
spurious to such a document. (Of course, the document doesn't actually
have this title, which makes a difference; more on this below.)
However, it's not as though any Scheme implementations are about to
eliminate the their REPLs - aside from myself, every one of the R6RS
editors was an implementor of Scheme, and every one of their Scheme
implementations offers a REPL, and none of them show any signs of
In this context, the idea that R6RS somehow intends to deprecate the
importance of the Scheme REPL is a misunderstanding. It's an
unfortunate one which seems to occasionally invoke visions of jackbooted
REPL-hating compiler writers goose-stepping their way to a takeover of
the Scheme world (it's no coincidence that one of the Scheme
implementations that lacks a REPL is named Stalin), but really, there's
no evidence that even the less fanciful real-world equivalent of this is
actually taking place.
In part, the issue here is a difference in perspective about the purpose
of the RnRS documents, and the implicit and not fully acknowledged
change in that purpose between R5RS and R6RS.
R5RS defined a large, relatively loosely specified family of languages,
which weren't very compatible with each other beyond a very small core.
In the interests of supporting portability of code between Scheme
implementations, R6RS defines a larger and more precise language, and
for the most part confines that language quite rigidly inside libraries.
It's true that R6RS doesn't capture the "whole" of Scheme. But neither
did R5RS. R5RS had the advantage that it didn't stop you from imagining
the Scheme you wanted - but this has the corresponding disadvantage that
everyone imagines a different Scheme, and portable code becomes problematic.
R6RS has the disadvantage that, if you allow your imagination to be
confined by its libraries, top-level programs, and (appendix-relegated)
scripts, which are precisely specified in the interests of portability,
it seems to stop you from imagining the Scheme you want.
But this is a misunderstanding similar to the one about REPLs - it
ignores the larger picture of what Scheme implementations do. Most of
the implementations of R6RS are essentially a mode of a more extensive
Scheme implementation. That seems unlikely to change any time soon.
The real issue here, then, is the relationship between "Scheme" and the
Report(s) that purports to describe it. Scheme is too big an idea to be
pinned down precisely by a single document.
I do agree that all of this raises many areas of potential improvement
over the R6RS process. Some of them have been discussed recently, but
I'll be concrete and repeat a few:
* The reason the REPL is completely unaddressed in R6RS is perhaps
primarily due simply to lack of manpower - R6RS was the most ambitious
of the Scheme Reports, and had one of the smallest teams working on it.
This is something that the new Steering Committee can address, via
working groups, subcommittees, solicitation of SRFIs, and other ways of
using community resources.
* I strongly believe that disagreements and misunderstandings about
rationales must be addressed by coming to agreement with the community
about goals, requirements and rationales early in the process, and
continuing this dialog as development progresses. This discussion with
the community can only increase everyone's understanding of the issues.
Having to justify changes after the fact is bad for both the authors
of a specification and for the community.
* It would be a good idea to have a clearer shared vision of the
intended purposes of the Scheme Reports. As touched on above,
regardless of anyone's intent, R6RS turned into something different in
nature from R5RS. Even those who are inclined to throw out R6RS and
restart from an earlier revision must recognize that they'll face many
of the same forces, if they plan to produce a specification for a
language that is portable across Scheme implementations. Perhaps there
is a justification for a document whose job it is to capture aspects of
the larger nature of Scheme that aren't necessarily relevant to the
"Report on the Definition and Use of Scheme Libraries" that I mentioned
above. Many people might care about one such document more than
another, which would be fine if it helps to satisfy more than one of the
various constituencies with an interest in Scheme.
* A few people have mentioned the idea of gaining experience with
proposed new features before standardizing them. Something along these
lines would be another big-impact way to improve the process, although
it would need significant ongoing cooperation from implementors.
More information about the r6rs-discuss