]> 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