On Apr 25, 2013 4:22 AM, "Alex Shinn" <[email protected]> wrote: > > On Wed, Apr 24, 2013 at 8:24 PM, Sam TH <[email protected]> wrote: >> >> On Wed, Apr 24, 2013 at 4:44 AM, Alaric Snell-Pym >> <[email protected]> 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
