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.
Paul Schlie wrote:
> - 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.)
Bounded exact numbers are not closed under arithmetic operations.
> - 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) ...)
That may seem more elegant, but consider these examples,
where I write flo+ and flo- to mean versions of the + and -
procedures that coerce their arguments to flonums before
adding or subtracting them.
((<float> list) 1.1 2.2)
= (list (<float> 1.1) (<float> 2.2))
= (list 1.1 2.2)
((<float> list) + -)
= (list (<float> +) (<float> -))
= (list flo+ flo-)
((<float> +) 1.1 2)
= (+ (<float> 1.1) (<float> 2))
= (+ 1.1 2.0)
((<float> +) 1.1 -)
= (+ (<float> 1.1) (<float> -))
= (+ 1.1 flo-)
((<float> +) 1.1 'a)
= (+ (<float> 1.1) (<float> '#(2.2)))
= (+ 1.1 ?????)
In terms of elegance, it seems sorta random to me for <float>
to be the identity on flonums, to coerce other numeric types
to flonums, to coerce procedures to procedures that map <float>
across their arguments, and to be an error on things that are
neither numbers nor procedures.
Will