[R6RS] another glimpse into the abyss

[William D Clinger]

Just a few quick reactions to Mike's post, mostly to
let him know someone read it.

Mike wrote:
> 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.

Larceny contains about 50,000 lines of cross-compiler
code that runs (or has run---I'm not going to test the
current status just to write this message) in Larceny,
MzScheme, Chez Scheme, Petite Chez, Gambit, MacScheme,
and MIT Scheme.

Larceny's user base is pretty small, but I know several
users of Larceny are maintaining portable R5RS programs
that are larger than 50,000 lines.

Multiplying the amount of portable code I maintain by
an estimated number of programmers who are maintaining
portable subsystems as large or larger than Larceny's,
I get a result that says backwards compatibility should
be taken seriously.

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

Speaking for myself, I think Scheme is far too firmly
wedged within the sequential von Neumann model for it
to serve as a successful substrate for parallel or
distributed programming, and the drift of the drafts
so far has been to make Scheme even more sequential
in several respects.  I have been dreaming of Grand
Larceny for many years, and regard its construction
as a more important use of my time than implementing
R6RS semantics, but I expect Grand Larceny to abandon
much of the sequential evaluation semantics required
by the Scheme reports.

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

What we have done so far is to *encourage* systems to
hide their extensions "below the radar", by defining
a brand-new concept of Scheme programs in which such
extensions are forbidden, while allowing arbitrary
extensions to be used in the kinds of Scheme programs
that people have actually been writing and using for
decades.

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

Mostly it entails an effort to design a language in
which programmers will want to write applications,
which should have started with an effort to identify
the actual problems real-world application programmers
face when trying to write their programs in R5RS Scheme.

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

I have pretty much given up on the idea that an
application programmer would want to program in
"conformant mode".  I think the many barriers to
extensions in the draft R6RS present formidable
obstacles to interoperation with external libraries,
and will have the effect of making those libraries
easiest to use in non-conforming modes.

As one concrete example, Common Larceny's JavaDot
notation can be supported only in non-conforming
modes.

The standard libraries of the draft R6RS won't even
let you get a listing of the files within a directory,
let alone register a Scheme procedure to be called in
response to some asynchronous event.  Most applications
will have to use external libraries.  That will require
use of non-standard and non-portable features, so it is
unrealistic to think that a conformant implementation
could support "most applications" unless, of course,
you adopt a rather arbitrary definition of that phrase.

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

Yes.  If "conforming mode" is going to be deprecated
or unavailable in most implementations of Scheme,
then it might as well specify right-to-left evaluation
of arguments, require exactly the right number of
values to be returned to all contexts (e.g. a command
context would require zero values), require map to
check for mutations to its list arguments between all
calls to its first argument, and so on and so forth.

If, on the other hand, "conforming mode" is intended
to be a realistic mode for writing portable programs,
then a more compromising approach is in order.

A poll of potential implementors' intentions might
shed some light, or at least heat, on this important
subject.

Will