[R6RS] another glimpse into the abyss

[Michael Sperber]

As to my own personal guiding vision, here are some random ramblings.
More specific response to Will's post further down below.

Most of it flows from the primary goal we formulated early in the
game, which is to improve the portability of Scheme programs.  As so
many barriers to portability are mostly due to the huge backlog of
changes that could have been made earlier, I'm quite happy with R6RS's
main achievement being making significant progress reducing that
backlog.

It's been clear throughout the process that much of the progress we
can achieve simply has to do with making choices between options that
have been available for a long time, and giving the result some
hopefully tasteful shape.  With some questions, however, such as the
module system, standards-oriented discussion has revealed a number of
options that would probably not have surfaced in a more "academic"
setting.  I was hoping we could leverage the R6RS process to make
progress on these questions, and we have made progress on at least
a few---not as many as I'd liked.

As a secondary goal, I was hoping we could continue a little bit on
the trajectory of previous Scheme reports and continue to refine and
clean up the language by improving what's already in R5RS.  As most
Scheme code that I want to use isn't currently portable anyway, I tend
to not see backwards compatibility as a very serious problem.
(Especially as we expect the Scheme community to grow by members who
don't know the culture-historical socio-political background behind
some decisions, and thus tend to be repelled by some of Scheme's
idiosyncracies.)

The rest is my own personal taste: I prefer several simpler,
orthogonal mechanisms to a bigger combined one with the simple
mechanisms as special cases.  I generally prefer explicit notations
over implicit ones.  I prefer separately named things over
overloading.  And so forth.  Blabla.

I guess that's not much of a personal vision, because so many of the
things I'd like to see are too far away to realistically hope for
them.  Fundamentally, I believe that Scheme can be an excellent
substrate for extensions in many directions, among them concurrent and
parallel programming, distributed programming, all kinds of DSLs,
without significant change of the substrate itself.  (However, given
that interactions tend to multiply, as with threads and dynamic state,
I think keeping things separate is more than just a matter of taste.)
With some of these things, we're only beginning to see how some of
these things are supposed to work, and thus the timing is quite good
for us: Some of the competition have prematurely standardized on
inferior abstractions, most notably Unicode.  Waiting one or two years
on things like threads will expose Scheme to better abstractions than
the ones we know now.

William D Clinger <will at ccs.neu.edu> writes:

> Many of these requirements, it seems to me, have little or nothing
> to do with memory safety, but are motivated by a desire to make
> non-portable programs harder to write.

That's certainly the case for me.  I probably disagree with you in
believing there's no fundamental difference: Where I work, the absence
of memory safety (in C++ programs) usually manifests itself as
non-portability, and that's how most industrial developers I work with
see the issue.

In my experience, programmers will use whatever they get: If a system
offers some functionality over what's documented and/or standardized,
somebody out there will use it.  If a system doesn't offer abstraction
barriers, programmers will cross the intended boundaries.

Witness the gradually increasing strictness with successive versions
of gcc: I conjecture these are mostly reactions to people writing lots
of unportable code, and most big software projects actually need to
make changes to make their code run through newer versions of gcc.  If
we don't do it now, I believe we'll end up making things more strict
in the future as a result of our experience.

This is fundamentally why I'd like to discourage Scheme systems from
offering extensions "below the radar", like accepting arguments to
R6RS procedures beyond what's specified.

> In my opinion, increasing the number of runtime checks for the purpose
> of stamping out non-portable usages is appropriate for code compiled
> at (debug 3), or maybe even (safety 3), but I question whether so much
> portability-related checking must be the default for production
> code.

I'm not sure that it must be the default.  However, I'd like to think
we could design the language so that it *could* be the default for
most applications.  I know this entails a number of compromises,
specifically in the area of run-time checks.

> If we accept that most Scheme programs will continue to run in
> interactive mode, to which the R6RS does not apply, or that most
> production R6RS programs are likely to run in some default mode that
> is unlikely to be strictly conforming, whatever that may mean, then
> the R6RS describes something of an idealized semantics whose
> requirements apply primarily when debugging portable programs.  If so,
> then shouldn't the R6RS semantics be even more idealized than it is?

As long as the semantics still allow a conformant implementation that
could realistically support most applications (for some arbitrary
notion of "most applications") in "conformant mode", I think it should
be more idealized.  You probably have something more drastic in mind
than I do, but I do believe idealization is possible on at least some
fronts.  (Such as multiple values / unspecified value.)

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla