[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inexactness vs. exactness



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