[r6rs-discuss] Now, where were we?

[Anton van Straaten]

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
> afterthought?  

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 
specifications.

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 
eliminating it.

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.

Anton