type of ==

type of ==

[Christophe DEHLINGER]

Hi all,

I was recently in a situation where I would have liked to be able to 
test physical equality on terms of possibly different types, but 
couldn't because of =='s 'a -> 'a -> bool type.
Why isn't its type 'a -> 'b -> bool ? Is there more to the 
implementation of == than a simple physical, asm-level equality test ?
Is it because of the semantics of == ? If so, is a 'a -> 'b -> bool 
equivalent possible / already existing ? I guess something like fun a b 
-> a == (Obj.magic b) should work, but regular posts on this list have 
gradually scared me off from ever using the obscure Obj module.

Christophe Dehlinger

__________________________

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
__________________________

Re: [Caml-list] type of ==

[Jon Harrop]

On Monday 18 April 2005 10:18, Christophe DEHLINGER wrote:
> I was recently in a situation where I would have liked to be able to
> test physical equality on terms of possibly different types, but
> couldn't because of =='s 'a -> 'a -> bool type.
> Why isn't its type 'a -> 'b -> bool ? Is there more to the
> implementation of == than a simple physical, asm-level equality test ?
> Is it because of the semantics of == ? If so, is a 'a -> 'b -> bool
> equivalent possible / already existing ?

If there were an "'a -> 'b -> bool" physical equality test, how could it ever 
return "true"?

> I guess something like fun a b 
> -> a == (Obj.magic b) should work, but regular posts on this list have
> gradually scared me off from ever using the obscure Obj module.

Yes, if you're writing self-contained OCaml programs then you should never use 
Obj.

You may find the beginners list more appropriate for these kinds of questions, 
BTW.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] type of ==

[Andreas Rossberg]

Jon Harrop <jon@ffconsultancy.com>:
>
> If there were an "'a -> 'b -> bool" physical equality test, how could it
ever
> return "true"?

Either when 'a and 'b happen to be instantiated to the same type, or when
the representation happens to be the same, e.g. 0 == false.

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.

Cheers,

  - Andreas

Re: [Caml-list] type of ==

[Christophe DEHLINGER]

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
__________________________

Re: [Caml-list] type of ==

[Jon Harrop]

On Monday 18 April 2005 13:11, Andreas Rossberg wrote:
> Either when 'a and 'b happen to be instantiated to the same type,

Yes, I realised this just after posting (thanks Diego!).

> or when the representation happens to be the same, e.g. 0 == false.

Assuming this is for an OCaml-only program, it sounds as though the "other" 
possible types 'a and 'b should be put into a single variant type. Then you 
can use "'a -> 'a -> bool" with "'a = your variant type". Does that make any 
sense? :-)

You'd have to indirect the physical equality once though, e.g.:

# type ('a, 'b) a = A of 'a | B of 'b;;
type ('a, 'b) a = A of 'a | B of 'b
# let compare_a x y = match x, y with
    A x, A y -> x == y
  | B x, B y -> x == y
  | _ -> false;;
val compare_a : ('a, 'b) a -> ('a, 'b) a -> bool = <fun>

A good excuse not to do this would be when you're writing a veneer between 
OCaml and C in OCaml.

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

Yes, although this is already the case when applying "=" to abstract types 
(implementation of the type in that case, rather than of the language 
itself).

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] type of ==

[Remi Vanicat]

On 4/18/05, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Monday 18 April 2005 10:18, Christophe DEHLINGER wrote:
> > I was recently in a situation where I would have liked to be able to
> > test physical equality on terms of possibly different types, but
> > couldn't because of =='s 'a -> 'a -> bool type.
> > Why isn't its type 'a -> 'b -> bool ? Is there more to the
> > implementation of == than a simple physical, asm-level equality test ?
> > Is it because of the semantics of == ? If so, is a 'a -> 'b -> bool
> > equivalent possible / already existing ?
> 
> If there were an "'a -> 'b -> bool" physical equality test, how could it ever
> return "true"?

Well, when I wrote my Weak memo module (see
http://aspellfr.free.fr/hweak/doc/Weak_memo.html), I add the need too
compare two object having a different type (too know if they are
actually the same or not). So I needed a egalyty having the type <..>
-> <..> -> bool

One could wrote one :

# let eq x y = (x : < .. > :> < > ) == (y : < .. > :> < >);;
val eq : < .. > -> < .. > -> bool = <fun>

But I don't know how to write it for polymorphic variant (without the
Obj module) for example, and someone may want to do a similar weak
memo on them (Notice that if one could write this, then one can do the
same on structural equality, and I'm not sure that one want to use
this on structural equality as I don't know what will appen if you try
to compare `Foo 10 with `Foo (10.) or some nasty things like that)

Re: [Caml-list] type of == - Bayesian Filter detected spam

[Christophe DEHLINGER]

Jon Harrop wrote:

>Assuming this is for an OCaml-only program, it sounds as though the "other" 
>possible types 'a and 'b should be put into a single variant type. Then you 
>can use "'a -> 'a -> bool" with "'a = your variant type". Does that make any 
>sense? :-)
>
>  
>
Alas, this does not work for me. This is for an OCaml-only module, in 
which the "other" types are all instances of one polymorphic mutable 
record type, but the number or exact values of these instances are not 
known within the module and may be pretty much anything.

Fortunately, I have an easy workaround in my case, but it can't really 
be generalized. The polymorphic record type contains a "node" field 
(which is a non-polymorphic mutable record). I know that two records 
cannot share the same physical node, so I basically use the node as a 
unique identifier for the records:

type ('a, 'b) my_record_type = { ... ; node : node_type ; ... }
let my_eq : ('a, 'b) my_record_type -> ('c,'d) my_record_type -> bool =
  fun x y -> x.node == y.node

Obviously, this method only works if you have such a unique identifier 
for every object you have to compare. If this node field hadn't been 
there, I would have been stuck with either cheating with the Obj module, 
or artificially adding a unique identifier to each record (like an int 
or a unit ref). The latter would have been quite frustrating, because it 
would cost execution time + memory + readability only to get around the 
arguably artificial typing limitation of == .

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
__________________________