> From: William D Clinger <xxxxxx@ccs.neu.edu>
>> Paul Schlie wrote:
>> Thereby hypothetically to keep things real simple, it may even be
>> considered reasonable to bound fixnums by a sign-less Inf (i.e. NaN);
>> effectively enabling basic balanced fixnums to be defined as:
>>
>>  NaN -(2^(P-1)-1) 0 +(2^(P-1)-1) NaN
>>
>> [where NaN is effectively = -2^(P-1), i.e. the pattern 10...]
>>
>> Thereby any overflow may be relatively easily detected, and trapped
>> to return NaN, which in turn closes all subsequent operations to
>> corresponding return NaN.
>
> This would work, but modular arithmetic is more useful when
> implementing bignums.  If you don't believe me, try it.

- I fully agree; the thought was merely a simple approach by which
  arithmetic operations may be closed on a finite set of integers in
  an analogous way that they are for floats, lieu of either modular
  arithmetic (which seems sufficient to me), or requiring the support
  of indefinitely precise integers (which create their own problems).

- Personally, it seems reasonable to require that a base implementation
  support only finite modular integers with a precision sufficient to
  represent the larger of:

  (integer-range) => <max-positive-representable-integer> or

  (length <list-of-all-allocatable-elements-for-a-given-implementation>)

> Egner et al advocated this.  One problem with this proposal
> is that exactness becomes contagious.  If a calculation was
> intended to use inexact arithmetic of bounded precision, any
> exact value that slips into the calculation inadvertently
> will result in exact rational arithmetic with increasingly
> large denominators; it will be very slow, and is likely to
> consume all available memory if the computation is nontrivial.

- seemingly a good reason for indefinitely precise exacts to be optional,
  and/or for them to bounded similarly to floats (and have the same
  dynamic range; thereby each float may map to a corresponding bounded
  exact, and each exact may map to a float within its precision.)

> Furthermore that proposal is completely at odds with Scheme's
> history, in which inexactness has been contagious, and with
> the coercion rules of nearly every other programming language.
>
> The solution adopted in SRFI-77 is to provide type-specific
> operations, so programmers can easily express what kinds of
> numbers they intend their computations to use, and mistakes
> will be detected and reported (in safe mode).

- just meant to state the opinion that it seems more elegant
  to preserve type-less operators, which may be extended with
  a cast syntax which extends beyond the operator to cast it's
  operands, i.e. in lieu of a typed +fl etc.

  ((<float> +) x y ...) :: (+ (<float> x) (<float> y) ...)