[my post was truncated by the "From " bug, so I'm trying again]
[subject line has changed; was "R5RS is not a baseline"]
The history of the editors' conversations regarding
interactive top levels illustrates the importance of
establishing requirements and goals.
Mike Sperber quoting me:
> > I remember the debates, but I do not remember occasions
> > on which I was asked to write it up.
>
> You even stated on several occasions that you don't want to argue that
> we should address the issue for the final report. As you were the one
> to whom it was most important among the editors, there was no follow-up.
When I said that, the draft R6RS amounted to a very
large SRFI that proposed to add a batch-mode notion
of "scripts" to R5RS systems.
Between December 2004 and April 2006, the editors' email
archives show almost no discussion of executable notions.
The minutes for the editors' telephone conversation of
24 May 2006 show that the following agenda item was added
at the beginning of that conversation [1]:
semantic model
- definitions: top-level, library-level, internal
- top-level, library-level, form-level
- what is a program?
- what things will have an R6RS semantics?
I believe that item was added to provide context for the
scheduled discussion and vote on an "evaluation model".
The minutes go on to report this:
- what things will have an R6RS semantics?
Matthew has proposed that libraries have R6RS semantics,
that programs do not have R6RS semantics
no semantics for top-level forms
If only libraries were to have R6RS semantics, however,
then there would be no base case for the recursive
importation of libraries by libraries, hence no way to
invoke a library, and the semantics of libraries would
be irrelevant.
Immediately following, the minutes show this:
- what about scripts?
consensus: we should try to define a notion of script,
with well-defined portable semantics
Mike will post something to start the discussion
Mike's follow-up took SRFI 22 as its model [2]. When
regarded as a replacement for SRFI 22, the R6RS did (and
still does) make sense.
Returning to the minutes of 24 May:
evaluation model (10 minutes)
- require expansion before evaluation?
yes: unanimous
- require syntax checking before evaluation?
yes: unanimous
- allow interleaved macro expansion, syntax checking, and evaluation?
no: see above
As I have explained above, these votes were taken when
the editors were thinking of the R6RS's evaluation model
as a batch-mode supplement to the R5RS, along the lines
of SRFI 22.
Apparently some editors later came to believe that the
R6RS should be regarded as a viable replacement for the
R5RS, but the votes of 24 May were never reconsidered
in that more ambitious context.
> Nobody argued something along the lines of "let's get rid of
> the top level, it's long been a thorn in my side".
In April 2004, Marc Feeley proposed a requirement or goal
for the module system: that it should work well for (1)
standalone statically linked programs, (2) dynamically
linked programs, (3) scripts, and (4) REPLs [3]. Matthew
argued against (4) and expressed reservations concerning
(2) [4]. Mike said he didn't think Marc's classification
was terribly useful [5]. The editors did not agree on
any requirements for the module system, and returned to
technical discussions without explicit goals.
The editors did not reconsider this issue until 24 May
2006.
> As for R6RS itself, I suspect a follow-up formal comment
> to #51 could well have done the trick for R6RS itself.
Anton's formal comment #51 was excellent, but the editors'
response was to make relatively minor changes, such as
replacing "script" with "program" [6]. Anton's larger
point was ignored: "What is then the point of going to
the trouble of specifying something in the interest of
portability if does not guarantee portability."
In my opinion, "the report blesses non-portable programs"
(in Anton's words) and fails to achieve the 24 May 2006
goal of "well-defined portable semantics" because the
editors never agreed upon clearly articulated requirements
and goals that could be used to evaluate their proposed
technical solutions.
By the way, people who submit formal comments should not
be expected to submit follow-up after follow-up when their
main points are ignored. They are more likely to give up.
> I am arguing that, despite the goodwill of the people involved,
> it's inevitable that some decisions leave people unhappy, and some
> decisions turn out to be mistakes later.
Agreed.
I am arguing that the frequency and magnitude of certain
kinds of mistakes can be reduced by paying more attention
to requirements and goals. That, I think, is the main
lesson to be learned as we go forward.
Will
[1] http://www.r6rs.org/r6rs-editors/2006-May/001313.html
[2] http://www.r6rs.org/r6rs-editors/2006-May/001314.html
[3] http://www.r6rs.org/r6rs-editors/2004-April/000091.html
[4] http://www.r6rs.org/r6rs-editors/2004-April/000093.html
[5] http://www.r6rs.org/r6rs-editors/2004-April/000094.html
[6] http://www.r6rs.org/formal-comments/comment-51.txt
_______________________________________________
r6rs-discuss mailing list
[email protected]
http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
