Re: [Caml-list] type of ==

[Christophe DEHLINGER <christophe.dehlinger@ifp.fr>]

Andreas Rossberg wrote:

>The latter also provides a good argument against making physical equality
>too polymorphic. It would break abstraction, much worse than it does
>already. In particular, a program's meaning could depend on implementation
>details (like false being represented by 0) in very questionable ways.
>  
>
It's arguable that it wouldn't be /that/ much worse than the current 
situation, where == on non-mutable structures is already implementation 
dependent.
I am not advocating for such a change though, if only because in most 
cases the arguments of == are known to be of the same type, so it is a 
good thing to be able to take advantage of this information. However, it 
would still be nice to have both equalities available (yes, I know, yet 
another equality). In the problem I'm working on, only mutable 
structures are compared, so the extended == would work as intended. Of 
course, you would have to know what you're doing when using this 
predicate, but this is already the case for the current two equalities : 
you have to watch out for the aforementioned non-mutable structures with 
== and for cyclic values with = .

Call me pessimistic, but I have little hope that this "feature wish" 
will be fulfilled, so I would happily settle for fun a b -> a == 
(Obj.magic b) (if it works, still haven't had a chance to try it). I'd 
be grateful if someone could tell me whether this particular use of 
Obj.magic is safe.

Christophe


__________________________

Ce message (et toutes ses pièces jointes éventuelles) est confidentiel et établi à l'intention exclusive de ses destinataires. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'IFP décline toute responsabilité au titre de ce message.

This message and any attachments (the message) are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. IFP should not be liable for this message.

Visitez notre site Web / Visit our web site : http://www.ifp.fr
__________________________