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

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

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.


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


Scheme-reports mailing list