[ERR5RS] Rationale and ease of use

[William Clinger]

Lynn Winebarger wrote:
>      If this is correct, could you (Andre, Will, or
> both) provide a single coherent explanation of why
> the separated binding are the better semantics?

You can construct examples for which separated
binding is the better semantics, and you can also
construct examples for which it is the worse
semantics.  In the R6RS editors' email discussion
(which I haven't had time to put into searchable
form since it were made public, or I would cite
the URL), I suggested that R6RS programmers should
be allowed to specify which semantics is used for
each library.  That went nowhere.

> In any case, as a user I would prefer to know that
> it was going to be one or the other for certain.

The plan is for ERR5RS to support a proper subset of
R6RS libraries for which this distinction doesn't
matter, so there is no need for users to know or to
care.

That can be done by having ERR5RS libraries import
and export syntax-rules macros only, or by allowing
syntax-case macros to use only a purely functional
subset of the language.

>      Also, is the goal to make it easy to convert
> libraries between ERR5RS and R6RS or to have the
> same code have the same semantics under both?

Both are goals.  The second goal is a little more
ambitious, and cannot be achieved in general
without making ERR5RS bug-compatible with the R6RS,
so we have to compromise a bit, generally by giving
ERR5RS a proper subset of the corresponding R6RS
syntax or API or semantics.  For example, we can
restrict the kinds of macros that can be imported
and exported by ERR5RS libraries.

The second goal usually implies the first goal, so
our discussions tend to focus on the second goal.
Most of those discussions aim to identify a subset
of the R6RS syntax/API/semantics that would be
appropriate for ERR5RS.

For most of our discussions, the design space is
constrained to be both a superset of the R5RS
syntax/API/semantics and a subset of the R6RS
syntax/API/semantics.  That keeps us focused
and simplifies the design task, which is key
to rapid completion of a successful ERR5RS.

Will



      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7