Physical counterpart to Pervasives.compare?

Physical counterpart to Pervasives.compare?

[Elnatan Reisner]

Is there something that can complete this analogy:
(=) is to (==) as Pervasives.compare is to ___?

That is, is there a polymorphic total ordering with respect to *physical*
entities, rather than to their structure?

I'm afraid of getting into trouble with Obj.magic, but what would this do:
let f (x:'a) (y:'a) = compare (Obj.magic x) (Obj.magic y)
? Or would annotations make any difference:
let f (x:'a) (y:'a) = compare (Obj.magic x : int) (Obj.magic y : int)

-Elnatan

Re: [Caml-list] Physical counterpart to Pervasives.compare?

[Edgar Friendly]

Elnatan Reisner wrote:
> Is there something that can complete this analogy:
> (=) is to (==) as Pervasives.compare is to ___?
> 
> That is, is there a polymorphic total ordering with respect to *physical*
> entities, rather than to their structure?
> 
No, but it'd be pretty trivial to implement through the C interface.

> I'm afraid of getting into trouble with Obj.magic, but what would this do:
> let f (x:'a) (y:'a) = compare (Obj.magic x) (Obj.magic y)
> ? Or would annotations make any difference:
> let f (x:'a) (y:'a) = compare (Obj.magic x : int) (Obj.magic y : int)
> 
> -Elnatan

Nope, Obj.magic and casting only have compile-time effects, the code
given compiles exactly the same as [let f x y = compare x y].

If you had to stay in the OCaml realm, you might be able to do [let
phys_comp (x:'a) (y:'a) = (Obj.magic x) - (Obj.magic y)], but it depends
on the exact implementation of (-) on your architecture, as it may
produce a value that's not an OCaml int when given non-ints as input.

E

Re: [Caml-list] Physical counterpart to Pervasives.compare?

[Edgar Friendly]

Edgar Friendly wrote:
> Elnatan Reisner wrote:
>> I'm afraid of getting into trouble with Obj.magic, but what would this do:
>> let f (x:'a) (y:'a) = compare (Obj.magic x) (Obj.magic y)
>> ? Or would annotations make any difference:
>> let f (x:'a) (y:'a) = compare (Obj.magic x : int) (Obj.magic y : int)
>>
>> -Elnatan
> 
> Nope, Obj.magic and casting only have compile-time effects, the code
> given compiles exactly the same as [let f x y = compare x y].
>
It looks like I'm wrong on this - there's versions of compare
specialized for floats, strings and ints.  Maybe you *could* trigger the
use of the caml_int_compare by this kind of type system manipulation.
It looks quite safe to use on non-ints.

Testing on your platform is possible, by trying to find store pointers
to ints, so that caml_compare compares the ints, but the tricked
caml_int_compare compares the pointers, and gets a different result.

E

Re: [Caml-list] Physical counterpart to Pervasives.compare?

[Alain Frisch]

On 7/29/2009 3:25 AM, Elnatan Reisner wrote:
> Is there something that can complete this analogy:
> (=) is to (==) as Pervasives.compare is to ___?
>
> That is, is there a polymorphic total ordering with respect to *physical*
> entities, rather than to their structure?

Not really. The physical location of heap values is not stable (because 
of the GC), so you cannot use it as a total ordering.

It may be useful to know that the generic structural comparison has a 
physical behavior for OCaml objects (it compares their unique ids). So 
wrapping your values inside objects can be a good trick to get physical 
comparison (and hashing), as in:

class ['a] physical_reference init = object
   val mutable current : 'a = init
   method get = current
   method set x = current <- x
end


-- Alain

Re: Physical counterpart to Pervasives.compare?

[Pascal Cuoq]

Christophe Raffalli <christophe.raffalli@univ-savoie.fr> wrote:
> Or, if all major GCs are compacting and the minor heap is at
> a higher adress than the major heap, then OCaml's could also
> preserve the adress order between GC ...

I do not think that the current minor GC algorithm does
any effort to copy the live blocks from the minor heap in order
(i.e. to copy first the blocks with the lower addresses).
It copies them as it finds them, recursively. Two blocks from
the minor heap may still see the order in which they are
in memory change when they are both copied
to the major heap.
For this reason, I do not think that the above trick would work.

Pascal