English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-08-09 (19:09)
From: Alain Frisch <alain@f...>
Subject: Re: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions
On 8/9/2009 8:56 PM, Elnatan Reisner wrote:
> My other issue is that the description of (==) for mutable structures
> doesn't specify that it is symmetric; reading the documentation
> literally only implies that e1 is a substructure of e2. Even just adding
> 'and vice versa' might clean this up:
> |e1 == e2| is true if and only if physical modification of |e1| also
> affects |e2 and vice versa|

It depends on what 'physical modification' and 'affect' mean. Clearly, 
the documentation means toplevel modifications of the values (i.e. 
modifying fields for record values, or elements for arrays or strings). 
If one includes deep modifications, then your extended criterion does 
not work either (think about two mutually recursive records).

> In terms of 'may not' versus 'does not' terminate, I just noticed that
> the current documentation for (=) says 'may not terminate' while the
> documentation for (>=) says 'does not terminate'. However, the example
> cited in the link above:
> type t = { a : t };;
> let rec x = { a = x } in x = x
> doesn't terminate in OCaml 3.11. This seems to be about as simple a
> cyclic structure as there is, so shouldn't (=)'s documentation say
> 'Equality between cyclic structures does not terminate.'?

Note that (=) sometimes terminates for cylic values.

# type t = A of t | B of t;;
type t = A of t | B of t
# (let rec x = A x in x) = (let rec x = B x in x);;
- : bool = false

> And is there any reason, aside from NaN values, that (=) does *not* use
> physical equality as a shortcut?

I think a custom comparison function for custom blocks can also specify 
that a value is not equal to itself.

> In any case, if I have a data structure which I know does not contain
> any NaNs (for example, maybe it doesn't contain any floats whatsoever),
> is there ever a reason I should prefer (=) to (compare x y = 0)?

No, I don't see any reason.

-- Alain