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

This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.

*To*: William D Clinger <will@xxxxxxxxxxx>*Subject*: Re: arithmetic issues*From*: bear <bear@xxxxxxxxx>*Date*: Thu, 19 Jan 2006 17:10:51 -0800 (PST)*Cc*: agj@xxxxxxxxxxxx, sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx, srfi-77@xxxxxxxxxxxxxxxxx*Delivered-to*: srfi-77@xxxxxxxxxxxxxxxxx*In-reply-to*: <E1EzK9Z-00023F-Uo@xxxxxxxxxxxxxxxxx>*References*: <E1EzK9Z-00023F-Uo@xxxxxxxxxxxxxxxxx>

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

**References**:**Re: arithmetic issues***From:*William D Clinger

- Prev by Date:
**Re: arithmetic issues** - Next by Date:
**Re: arithmetic issues** - Previous by thread:
**Re: arithmetic issues** - Next by thread:
**Re: arithmetic issues** - Index(es):