[ERR5RS] Direction (was Bindings in R5RS vs R6RS)

[Lynn Winebarger]

I want to second part of David's email, and expand the scope of the issue.

On 9/15/07, David Rush <kumoyuki at gmail.com> wrote:
> There seems to be something of a debate building up over top-level
> semantics and how to deal with the immutablity and library constraints
> of R6RS in light of the very different model presented by R5RS. In
> short, R6RS seems very oriented towards static analyses (such as those
> performed by most compilers); but R5RS is much more oriented towards a
> constantly mutating REPL.
>
> I'm becoming convinced that these are not interoperable views, and ....
>[snip]
   I agree with David: we need to decide what direction ERR5RS is
going to take before too much effort is expended going in a direction
that will not meet the mandate.
   For example, I put up some questions for which I thought would be
easy to achieve consensus.  One was simple and administrative, to make
future reference to decisions and discussions easier.
    Another was to take all but the smallest unavoidable changes of
the R5RS off the table.  This has the advantage of limiting the scope
of our work, as well as removing many ancient issues from
consideration.  For example, I would just as soon remove dynamic wind
from the standard language and put it in a library.  Adopting this
proposal would prohibit me pursuing this.  Nonetheless, I appear to be
the only taker.  Is it open season for #f = '()?
    We are seeing some of the conflict inherent in the nuanced view
expressed by the "Requirements and Goals" document.  R6RS
compatibility appears to be far more important to some people than it
is to me.  To my mind, our primary audience are the R5RS implementors
who rejected R6RS.  R6RS is a competitor.  I probably wouldn't be
working on ERR5RS if R6RS did not set the bar so low for a successor
to R5RS.  As such, I think we should be looking at extending R5RS, as
opposed to retracting R6RS.  As a practical matter, the official R6RS
still has not been released, and their are few, if any, programs that
rely on it, where R5RS has existed for many years and there has been
substantial programs written based on it.  The question of porting
R6RS libraries to ERR5RS would be moot if we produced a better
standard and got these future libraries written against ERR5RS in the
first place.
     I feel stuck, because the time to object and revise the
"Requirements and Goals" for greater clarity of purpose was when Will
requested we revise the announcement.  I am guessing the intent of the
nuance is to embrace the range of people who rejected R6RS, from those
who did so on general principle to those who might have voted for
ratification except for some particular technical and/or process
issues, and even those who did ratify R6RS.
   There is no point in replaying the futile exercise that drew the
R6RS process out so long:  the lack of a convincing winner among the
various semantics of modules and macros.  The R5.97RS document binds
the hands of the implementors in various unpleasant ways without
enough certainty of interpretation in return.  We should decide now
whether we will (a) embrace the portable subset of R6RS libraries and
merely extend that to an interactive environment, or (b) extend the
R6RS library system with options to make various semantic choices
explicitly [and make it work in an interactive environment].  My
preference is for (b).  Andre's implementation of R6RS libraries in
R5RS shows that the separated bindings/phasing can be embedded in a
REPL semantics with appropriate alpha-conversion to separate binding
in phases.  I think REPL semantics can probably be embedded in the
fully separated phase model by making every define occur in its own
library and arranging their dependencies in a linear fashion (another
play on CPS), though I don't have an existence proof in the form of a
program.    The provision for communicating between modules by state
in a shared dependency is a separate parameter that could be mandated
for the library needing the state.  These mapping should give the
implementor sufficient freedom to use their preferred techniques while
not binding up the user or leaving so many programs ill-defined.  In
fact, if the library system is viewed as a means of transporting code
into multiple implementation philosophies of R5RS, then this maximal
approach is an excellent fit.
      If we decide that (a) is the route to follow, then no extensions
should be part of the standard, optional or not.  There is too much
contention to appear to privilege the status of one strategy.  I
realize (b) may be seen as distasteful in adopting such
inconsistencies, but I think any library system that does not embrace
the inconsistency is going to have a hard time succeeding, due to this
"life-raft between implementations" quality.

     I also believe we should adopt at least some soft deadlines if
there is to be any realistic hope of "weeks and months, not years."
If not deadlines, then at least milestones.  What does that phrase
mean, anyway?  Is a time frame of less than 6 months conceivable?

     I would just as soon limit ourselves to the libraries and maybe
lexical syntax.

> I'm posting here, because this issue cuts across many of the ERR5RS
> wiki pages. In short:
>
    I think my "polling place" came across more formally than I
intended.  I had in mind something along the lines of the periodic
polling seen in the meeting notes of the RnRS authors, where various
issues get sounded out.  We don't have face-to-face or even conference
call meetings, after all. Another goal was to take issues that might
be ignored, developing in a corner of the wiki somewhere, and get some
guidance prior to unnecessary thrashing.  If responses are nested (but
preferably with everyone making some "top-level" statement), it would
have the email-thread-without-pagination property Harold has described
as desirable..

Lynn