Re: [Scheme-reports] EQV? on numbers should be based on operational equivalence

[Ray Dillinger <bear@x>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/08/2012 03:28 PM, Per Bothner wrote:
> On 05/08/2012 12:06 PM, John Cowan wrote:
>> Andrew Robbins scripsit:
>> 
>>>> I believe that they are not: no R7RS (or R6RS, for that
>>>> matter) standard procedure can distinguish between one NaN
>>>> and another.
>>> 
>>> I beg to differ. Consider the functions:
>> 
>> [neat hack using bytevectors snipped]
>> 
>> Right enough.  I suppose such bytevector hacks will have to be
>> removed from the definition of "operationally equivalent" if it
>> is to be adopted. R3RS already excludes eq? and eqv? as well as
>> functions defined in terms of them, such as {mem,ass}{q,v}.
> 
> Why?  If two number written out to bytevectors (or binary files in
> general) have different bit-patterns, they're not operationally
> equivalent, and they're not eqv?.  What is the problem?


I opine that the problem is that the effect of writing an object
such as a NaN to a bytevector is shown by these functions to be
insufficiently specified.

A high-level language such as scheme ought to treat values as values
according to their types, not as bit layouts.  Control over bit
layouts should be purely for external purposes; reading/writing binary
formats and interfacing with ABI's.

Internal objects (characters, numbers, etc) ought to be treated
purely as values.  If there is a "hack" by which we can see their
bit layouts, or even distinguish bit layouts of otherwise operationally
identical objects, I say that an abstraction barrier has been violated
and the bug that allowed it needs to be fixed.

If we were talking about assembly language, or C, or one of those
languages where binary layouts are part of the fundamental semantics
of data, my opinion would of course be different.  In those languages
there is no abstraction over binary layout, and thus no breakage of
an abstraction barrier.  But I don't think that's what we want scheme
to be.

					Bear

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPqbAdAAoJEAOzWkqOibfNVZMH/iIkFszLrMuA3AmzC0Llx5dh
Fe8iwLM3QzEmm79K9sBlC18MCHuNEWZWaJj+QbEioTduZ9plkYhi/tcUUZQEqh03
1KvEksqFZMaqrmi4A5hFpp2njhfd1gcsOuc8mlaI93pHvzaK3J83woe1dqLm0t1X
z4C2MY43IfCbNTG6icpBJnb4fFHC7cCTkL3lA4037iKdM8oTWd8gdB2ha3uakcqF
9Z74cwWD7SnxGOFXzEnjT5r4P+rkERD85aIs8VVyvC6J8Ay7IuTpKJ4VPeea0YFi
Rs12oKVuvi9jnYw69crzujAwh5jkoSVG7mN9cCMp8yxaId8boAGPDpod8a60/+E=
=Yl+H
-----END PGP SIGNATURE-----

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