This page is part of the web mail archives of SRFI 70 from before July 7th, 2015. The new archives for SRFI 70 contain all messages, not just those from before July 7th, 2015.
This mailing list is not really the right place to say what I'm about to say, but it's more appropriate than many venues because SRFI-70 has so much to do with principles of language design. Mike Sperber wrote: > This thread is no > proof, but certainly an indication that there is a certain amount of > confusion over the nature of exactness in R5RS. Indeed. When an excess of authoritative-sounding opinions are combined with a dearth of fact, confusion usually results. For example, you and I know that the R5RS semantics of arithmetic was designed to allow systems to implement the computable reals, and that (some of) your paper's proposals were designed to disallow the computable reals, but I doubt whether those facts are known to many of the Scheme programmers who have been expressing their opinions about the semantics of inexact arithmetic in Scheme. The larger issue is one of programming language design. Some believe that the specification of a programming language should be categorical, as with the axioms of Euclidean plane geometry; others believe that the specification should admit many models, as with group theory. Many of the arguments I have seen in the Scheme community ultimately come down to an argument between those two extremes. In my view, the extreme proponents of both extreme positions are too extreme. Those who believe that the specification should be categorical are doomed at the outset, of course, because categoricity is impossible for theories that are as expressive as programming languages. At the same time, portability requires facts on which portable programs can rely. The more such facts, the fewer models. In my view, one of the hardest parts of language design is to strike a good balance between two fundamentally incompatible goals: to allow as many models as possible while guaranteeing as many facts as possible. I hope that making this goal/conflict explicit will lead to more productive discussions about language design, and to better designs. Will