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 [email protected] people who still have processes running, and kill them." _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
