Re: [Caml-list] Strange physical equality behavior

[Oleg Trott <oleg_trott@columbia.edu>]

On Sunday 09 November 2003 08:33 pm, Jacques Garrigue wrote:
> From: Oleg Trott <oleg_trott@columbia.edu>
>
> >         Objective Caml version 3.07+2
> >
> > # sin == sin;;
> > - : bool = false
> > # let f = sin;;
> > val f : float -> float = <fun>
> > # f == f;;
> > - : bool = true
> >
> > I don't like the fact that (sin == sin) returns false.
>
> This is coherent with the specification of (==), which says that
> it is fully specified only for mutable structures.
> (** [e1 == e2] tests for physical equality of [e1] and [e2].
>    On integers and characters, physical equality is identical to structural
>    equality. On mutable structures, [e1 == e2] is true if and only if
>    physical modification of [e1] also affects [e2].
>    On non-mutable structures, the behavior of [(==)] is
>    implementation-dependent; however, it is guaranteed that
>    [e1 == e2] implies [e1 = e2]. *)

<snip>

So returning "true" for "sin == sin" and "sin = sin" wouldn't break the above 
guarantee.

Here are my reasons for wanting such behavior (not just for "sin" of course, 
but also "(+)" , etc., and especially for "compare"):

As was discussed lately [1], the functorial interfaces (as used in the 
standard library) are somewhat clumsy. One solution could be to pass the 
necessary ordering and hashing functions as optional parameters to "emtpy" or 
"create". However, in this case, functions would need to be compared at 
runtime

compare_functions f g = try f = g with _ -> false

So e.g. "compare == compare" returning true would be a lot more convenient

[1] http://groups.google.com/groups?selm=fa.cvslsk1.37iiq9%40ifi.uio.no


-- 
Oleg Trott <oleg_trott@columbia.edu>

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners