On Wed, 18 Jan 2006, William D Clinger wrote:

>Bear set forth seven arguments in favor of type declarations.
>His sixth point was:
>> 6) Optionality:  Scheme systems are *NOT* required to use the information
>>    available in type declarations for optimization or checking purposes.
>
>Optional type declarations cannot possibly require all
>implementations to behave similarly.  Therefore optional
>type declarations cannot possibly solve the portability
>and predictability problems that are the main focus of
>SRFI-77.

You've promoted semantics which are mere accidents of hardware
implementation to the level of requirements.  I firmly believe
that any scheme code which relies for its correctness on an
overflow or a roundoff is in error, so your "type specific
operations" are seen as implementing things which are not, in
fact, correct representations of the operations after which
they are named.

An optional declaration has one great benefit; it absolutely
does not change the semantics of the code.  Addition is still
addition, and an overflow or a roundoff is still a *WRONG ANSWER*.

If you want functions that rely on those exact wrong answers as
correct, in fact providing mathematical operations that obey
different semantics,  I believe that they ought to be provided or
exposed only in specialized circumstances or when someone
specifically requests them, and that a reference implementation
or definition of them ought to be done in the general mathematics
of exact unlimited-size integers so that code using them can be
run on machines whose hardware types do not in fact match the
expectations of roundoffs and rollovers.  I do *NOT* believe
that scheme mathematics ought to be defined in terms of them.

Scheme mathematics (probably including minimum standards for
inexact numbers if we want to get them uniform and operations
defined in terms of them portable) should be defined in terms
of operations on the infinite set of exact integers.

I  am happy with the situation where

(the fixnum (+ (the fixnum x) (the fixnum y)))

generates correct (ie, without roundoffs) code for
arguments and results which are in fact fixnums and
is an error for arguments or a result which are in
fact not fixnums (in this case, likely an overflow
error resulting in a WRONG ANSWER).

The declaration in this case is simply a promise to the
compiler that it doesn't have to check for or generate
code for other numeric types with this particular addition.
If the programmer breaks that promise, then an error
results.

If the compiler generates such code anyway, it does not
affect the semantics of the program where the assertion is
correct.  And that is the semantics of optional declarations.

				Bear