Alex Shinn scripsit:

> My preference is to remove the entire section about R6RS.

Unfortunately, the WG voted to have it there.  However, I am willing
to change my vote, and if either Arthur or Alaric will do the same,
then we can flush it and reclaim a whole page.  Given the amount of
headache it has been, I would urge this action.

> It's the job of the small language to be compatible of R5RS,

Indeed.

> and the job of the large language to be compatible with R6RS,

The requirement is a carefully hedged compromise between the chair (who
wanted a fairly strong guarantee of compatibility) and the Steering
Committee (who did not).  It reads "Insofar as practical, the language
should be backwards compatible with an appropriate subset of the R6RS
standard."

By comparison, the WG1 charter requirement says "Insofar as practical,
the language should be backwards compatible with the IEEE standard,
the R5RS standard, and an appropriate subset of the R6RS standard."
Given that WG2's language must be a superset of WG1's language, this
effectively imposes the same weak requirement for R6RS compatibility
on both.

It is is the chair's intention to attempt to ensure that everything in the
R6RS is "covered" somehow by the large language, but that is certainly far
from being a promise of backward compatibility.  As a trivial example,
it is hardly likely that WG2 will impose the R6RS library system on
conforming implementations of R7RS-large, though it is already known
that some implementations will provide both.

--
"Repeat this until 'update-mounts -v' shows no updates.         John Cowan
You may well have to log in to particular machines, hunt down   cowan@ccil.org
people who still have processes running, and kill them."