I've just crystallized a thought that has been running through my head
for the past few days.
What is the point of creating an R7RS?
Those of us who use Scheme regularly are generally pretty happy with
our various implementations. Gambit, Chicken, PLT, Chez, etc. are all
quite useful for building quite large and complex systems, and we all
know how to port code from one of these to another without that much
hassle. (I often say that porting reasonably-written code from any
good Scheme system to another is about as difficult as, or maybe less
difficult than, porting SQL code from Oracle to PostgreSQL.) So why do
we need a new standard at all?
Others will say that standardization offers us the ability to strip
away some or another piece of cruft that should never have been in the
language at all. I have some considerable sympathy for this viewpoint;
I believe that Unix achieved its perfection with Seventh Edition Unix
in the mid-70s, and that it has been downhill from there (Plan 9 was
built as an attempt to recapture that Unix elegance, and we all know
how well it did). But in fact, we already have our perfection before
us, in the Lambda Papers. Everything since then has been added because
somebody thought it would be useful, obviously taking away from the
pristine elegance of pure lambda calculus (plus, admittedly, MacLisp).
So there must be some other reason why we need an R7RS. Here's my claim.
R7RS is not primarily for us, but rather for the
people who ought to be using Scheme but aren't.
Those people perceive:
- Scheme is only for toy programs.
- At present, Scheme is fractured into many dialects, all so
incompatible as to make programs inherently nonportable.
- To find out what Scheme is, you have to navigate a maze of
reports, SRFIs, manuals, and blog postings, and maybe read the source
code for your implementation.
- Because of these reasons, nobody in the `real world' uses Scheme,
and therefore it's just a waste of time.
(There are other falsehoods, such as that Scheme systems are
necessarily slow, but an R7RS isn't much of a cure for these untruths.)
So an intelligent person might peruse a well-written R7RS, and conclude:
- if I am a teacher, I can use Scheme to teach core concepts in
computer science/software engineering, without a whole bunch of
unnecessary or weird features that get in my way; furthermore, I can
share curriculum materials with people who happen to be using
different implementations
- if I build embedded systems, I can use a core of Scheme that (a)
has a good memory footprint and good performance, and (b) has the
ability to connect to the system components I need to access
- if I build conventional applications, the language offers me the
range of facilities I expect from other languages, as well as unique
features that improve my ability to develop sophisticated, reliable
programs
(Of course, in a sense, R7RS *is* for Schemers, too. We want our
implementers, as much as is practical, to agree on a core of basic
things, so as to help us port easily. I just think that the non-
Schemer audience is more important for the success and growth of
Scheme.)
R7RS, therefore, needs to accommodate these three audiences. I'm not
sure about which kind of presentation is best for this, but probably
the most important thing the R7RS Editors (who may or may not be a
smaller group than the set of WG members) can provide is an overall
map that defines what's where, so that one knows where a hash table
specification can be found, if it's not in the main Ultra-Scheme
document. (A language that doesn't have hash tables as a predefined
datatype will get slammed by the Perl/Python/Ruby crowd AND the Java/
C# crowd, so pointing at a SRFI or saying that the implementation
might provide hash tables or commenting that any computer science
student who's taken data structures can implement them will not
inspire confidence in a prospective Schemer.) By contrast, an HTTP
client is very clearly an application library; nobody except a Python
programmer would think of it belonging in the core language
specification. Libraries like this are better handled by some of the
emerging library sharing initiatives, rather than by a Report. Regular
expressions fall midway between: I'd tend to classify them as library
rather than R7RS material, though.
I'm unable to present my thoughts without some kind of concrete
example. I am explicitly not saying I want the Editors to produce
these documents, just that this is one of many ways of organizing a
Report that embodies the vision I have.
- Top Level Guide to R7RS Scheme
- Core Subset Specification
- Ultra-Scheme Specification
- Additional Specifications
- Embedded Systems Features
- Collections and Data Structures
- Threads \
- Environments |------ these are just examples
- Object System /
- ...
- Rationale
- Non-normative appendix on conventions and operating system
interface
As a computer science teacher, I can then say I need the Core Subset
plus Collections. An embedded application may want the Subset plus
Embedded System Features (whatever that is) and Threads. An
`everything but the kitchen sink' implementation may offer the full
Report (perhaps with a PLT-ish way of turning off unwanted features).
The Top-Level guide helps me navigate, so I know up front the total
set of features R7RS can comprise, if I ask for a full implementation.
(As a side note, I think the R6RS Rationale is a good start, but much
more should be done with it, again to explain to a prospective Schemer
why certain choices were made.) On a first pass, the Committee could
skip all the Additional Specifications; my point is that whatever
people think of as controversial (A: `I will kill myself if forced to
use a Scheme without this feature'; B: `I will kill myself if forced
to use a Scheme WITH this feature') can be pulled out into an
Additional Specification.
This somewhat contradicts my earlier stand on options. What I was
reacting to with our earlier discussion of options, I now see, was
that I perceived a fine granularity on them. I don't want a Report
that says that set-cdr! is `inessential' or `optional'. Either include
it or don't include it. The granularity level shouldn't be at the
individual procedure level, but rather at the feature level: not hash
tables, but collections; not fork, but POSIX support; and so on. This
vastly reduces the combinatorial explosion inherent in a large number
of fine-grained options.
I think all too often learning Scheme is like that scene in `A Day At
The Races' where Groucho is off to the races, and encounters Chico,
who offers to sell him a tip book on the horses. Groucho buys it, only
to discover it's in code, so he must buy a code book. Metacircularly,
it turns out that the code book is itself in code, and therefore
Groucho needs a code metabook. (It's too bad Chico didn't have a Y
combinator in his pile.) By the time Groucho has bought the huge pile
of books he needs, the race is over.
In my opinion, R7RS is an opportunity to get our stories out, and do
so in a consistent manner. I strongly urge the Committee to keep in
mind this audience for the final Report.
-- v
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
