This site is updated infrequently. For up-to-date information, please visit the new OCaml website at ocaml.org.

[Caml-list] Strange physical equality behavior
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
 Date: 2003-11-10 (02:25) From: Oleg Trott Subject: Re: [Caml-list] Strange physical equality behavior
```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