On Apr 25, 2013 4:22 AM, "Alex Shinn" <alexshinn@gmail.com> wrote:
>
> On Wed, Apr 24, 2013 at 8:24 PM, Sam TH <sam@alumni.uchicago.edu> wrote:
>>
>> On Wed, Apr 24, 2013 at 4:44 AM, Alaric Snell-Pym
>> <alaric@snell-pym.org.uk> wrote:
>> > I hear the complaints from
>> > people that our rejection of R6RS has been a mistake, but that was the
>> > scope of the requirements laid down by the Steering Committee
>>
>> Certainly the charter didn't *require* R6RS compatibility, but it
>> didn't *prohibit* it.  For example, the decisions not to make the
>> module system or the error system or the struct system compatible were
>> decisions that the working group took that could have gone the other
>> way.
>
>
> Sam, thank you for providing a rationale with your vote and for
> including specific points.
>
> I think it's somewhat hypocritical to cite these specific examples
> though.  R6RS chose to break compatibility with the widely
> implemented and used SRFI-9 and SRFI-23, and provided a
> module system incompatible with R5RS and most existing module
> systems.  We were thus forced into a decision that was incompatible
> with one or the other either way.  You can of course disagree with
> our decisions, but you can't take the moral high ground here.

First, I want to emphasize that I was not an editor of R6RS, I was not
involved in its drafting, and thus the charge of hypocrisy is
unreasonable.

Second, SRFIs are not standards, they are (at least in these
instances) the _failure_ of standards. Breaking compatibility with
them is not the same as breaking compatibility with the ratified
Scheme report.

> The module system compatibility perhaps needs clarification.  The
> primary goal of the WG1 charter - which I strongly agree with -
> was to improve Scheme compatibility.  To provide a common
> ground for implementations to share code.  To this end, by far the
> most important property is that the module system be supported
> and that it not be second class.  You should be able to import
> native modules from portable modules and vice versa, and there
> should be no loss of performance.

Once you write sentences about "native modules" and "portable
modules", you should recognize that the standards game is up. At that
point, we should recognize that Scheme is a language family, not a
single language, and have meetings to share ideas, not a standard.

Also, the module system breaks compatibility with existing R5RS
programs because giving a portable semantics to R5RS-style top-level
programs is impossible.  See Matthew Flatt's points under the rubric
"the top level is hopeless" for more here [1], or more on point, the
fact that R7RS makes no attempt to actually standardize any of the
hard cases here.

Finally, the R6RS module system addresses important and challenging
problems that R5RS did not, which R7RS instead abandons.  See Aaron
Hsu's message for more on this.

> As mentioned already, R6RS actually makes it impossible to
> use existing R5RS code unmodified, but more than that the
> versioning and phasing features make it impossible to integrate
> with most existing module systems.  R7RS has neither of these
> problems.  Further, since we moved the complex and controversial
> versioning and phasing issues to WG2, choosing a superficially
> different syntax actually improves R6RS compatibility.  You can
> support both library and define-library as in Sagittarius, so it's
> misleading to say R7RS modules are incompatible with R6RS.
>
> Again, the decisions are debatable, but the time for debate is
> long over.  The charter was finalized over three years ago, the
> formal comments period ended over half a year ago, and the
> community provided constant feedback in the interim.  You can
> disagree now, but keep in mind it was R6RS that broke backwards
> compatibility and hampered forwards compatibility long before
> any of this.

R6RS was forced to break backwards compatibility because
fully-compatibly moving forward from R5RS was not possible.  R7RS
demonstrates this by breaking compatibility again in some of these
areas, and by not moving forward in most.

Sam

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports