On 02/20/2012 03:58 PM, Aubrey Jaffer wrote:
>   | Date: Mon, 20 Feb 2012 11:12:07 -0800
>   | From: Per Bothner<per@bothner.com>
>   |
>   | On 02/20/2012 09:12 AM, Aubrey Jaffer wrote:
>   |>
>   |>  EQ? is allowed to distinguish different NaN values.  It is better
>   |>  to let EQ? make this distinction than EQV?.
>   |
>   | EQ? can distinguish the "same" values as being different:
>   |     (eq? 2.0 2.0) =>  unspecified.
>   | Thus it is uninteresting in this context.
>
> You proposed distinguished NaNs as an optional feature, not a required
> one.  Allowing EQV? to distinguish NaNs weakens its portable contract.

Sometimes that is the right thing to do for a standard, since you
allow an implementation to match different environments and goals.

> EQ? already is allowed to distinguish NaNs, so its contract need not
> be changed.  An implementation wanting to have distinguishable NaNs
> just makes its EQ? reflexive, which is also allowed by R7RS.

eq? traditionally is implemented by comparing object "pointers".
(I use quotes because of fixnums and other direct values.)
The expectation is that it be simple and cheap.  This simple
and cheap implementation makes eq? useless for comparing numbers,
unless numbers are either unboxed or interned, which is not something
we can reasonably expect of an implementation.

Note there could potentially be 2^52-1 different NaNs, so pre-allocating
them is not an option.  Even interning as needed adds overheads.  Of
course using all these NaNs is unlikely, but one can imagine using
those bits for special purposes, and wanting Scheme to not drop the
information in them.

So, I repeat, eq? is uninteresting in this context, even if the eq?
is "allowed" by the standard to distinguish different NaNs.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports