[Caml-list] Semantics of physical equality

[Caml-list] Semantics of physical equality

[Kevin S. Millikin]

I'm trying to figure out what I can rely on about physical equality. 
 I've checked the OCaml manual but can't seem to find what I want to 
know.

Presume

# type t = V0 | V1 of int;;
type t = V0 | V1 of int

# V0 == V0;;
- : bool = true

V0's are the same.  Is this guaranteed?

# V1(0) == V1(0);;
- : bool = false

V1's are different.  Is this guaranteed?

----
Kevin S. Millikin           Architecture Technology Corporation
Research Scientist          Specialists in Computer Architecture
(952)829-5864 x162          http://www.atcorp.com

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

Re: [Caml-list] Semantics of physical equality

[Basile STARYNKEVITCH]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1892 bytes --]

On Fri, Feb 27, 2004 at 02:29:50PM -0600, Kevin S. Millikin wrote:
> I'm trying to figure out what I can rely on about physical equality. 
>  I've checked the OCaml manual but can't seem to find what I want to 
> know.
> 
> Presume
> 
> # type t = V0 | V1 of int;;
> type t = V0 | V1 of int
> 
> # V0 == V0;;
> - : bool = true
> 
> V0's are the same.  Is this guaranteed?

Yes.

> 
> # V1(0) == V1(0);;
> - : bool = false
> 
> V1's are different.  Is this guaranteed?

What do you mean by guaranteed? This is true, but it might become
false:

a) because the compiler optimize a common constant subexpression

b) because the runtime might make these 2 values become the same (ie
   by hash-consing).

c) there is a tricky issue regarding floating point compares for
NaN. Read the source code or some previous posting on this (I never
used NaN since I am not a numerical coder).

As far as I know, neither a nor b is currently true (both in
Ocaml3.07pl2 and in the latest CVS), but I could imagine that some
later version of ocaml might do a or b (even if I believe this
unlikely).

The only reasonable implication about physical equality is 
  a == b  implies a = b

(ie physical equality implies structural equality)


Why would you want a guarantee that V1 0 is not physically equal to V1
0? I tend to think that making such an hypothesis is dangerous and
wrong, even if the current implementation demonstrate it.


Regards.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/ 
email: basile<at>starynkevitch<dot>net 
aliases: basile<at>tunes<dot>org = bstarynk<at>nerim<dot>net
8, rue de la Faïencerie, 92340 Bourg La Reine, France

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

Re: [Caml-list] Semantics of physical equality

[Michal Moskal]

On Fri, Feb 27, 2004 at 10:32:29PM +0100, Basile STARYNKEVITCH wrote:
> On Fri, Feb 27, 2004 at 02:29:50PM -0600, Kevin S. Millikin wrote:
> > I'm trying to figure out what I can rely on about physical equality. 
> >  I've checked the OCaml manual but can't seem to find what I want to 
> > know.
> > 
> > Presume
> > 
> > # type t = V0 | V1 of int;;
> > type t = V0 | V1 of int
> > 
> > # V0 == V0;;
> > - : bool = true
> > 
> > V0's are the same.  Is this guaranteed?
> 
> Yes.

Is it?

"On non-mutable structures, the behavior of (==) is
implementation-dependent;" [1]

[1] http://caml.inria.fr/ocaml/htmlman/libref/Pervasives.html

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?

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

Re: [Caml-list] Semantics of physical equality

[sejourne kevin]

 --- Michal Moskal <malekith@pld-linux.org> a écrit :
> On Fri, Feb 27, 2004 at 10:32:29PM +0100, Basile
> STARYNKEVITCH wrote:
> > On Fri, Feb 27, 2004 at 02:29:50PM -0600, Kevin S.
> Millikin wrote:
> > > I'm trying to figure out what I can rely on
> about physical equality. 
> > >  I've checked the OCaml manual but can't seem to
> find what I want to 
> > > know.
> > > 
> > > Presume
> > > 
> > > # type t = V0 | V1 of int;;
> > > type t = V0 | V1 of int
> > > 
> > > # V0 == V0;;
> > > - : bool = true
> > > 
> > > V0's are the same.  Is this guaranteed?
> > 
> > Yes.
> 
> Is it?
> 
> "On non-mutable structures, the behavior of (==) is
> implementation-dependent;" [1]
> 
> [1]
>
http://caml.inria.fr/ocaml/htmlman/libref/Pervasives.html

Ho!
A definition for mutable structures look ambiguous to
me:

type test = 
	{
	mutable a:int;
	b:int
	};;

let r = {a=0;b=2};;

let x = r and y = r in 
assert((x.a==y.a)&&(x.b==y.b)&&(x==y))
;;

Does this always ok ?



	

	
		
Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! 
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/

Dialoguez en direct avec vos amis grâce à Yahoo! Messenger !Téléchargez Yahoo! Messenger sur http://fr.messenger.yahoo.com

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

Re: [Caml-list] Semantics of physical equality

[Andreas Rossberg]

sejourne kevin <sejourne_kevin@yahoo.fr> wrote:
>
> http://caml.inria.fr/ocaml/htmlman/libref/Pervasives.html
> 
> Ho!
> A definition for mutable structures look ambiguous to
> me:
> 
> type test = 
> {
> mutable a:int;
> b:int
> };;
> 
> let r = {a=0;b=2};;
> 
> let x = r and y = r in 
> assert((x.a==y.a)&&(x.b==y.b)&&(x==y))
> ;;
> 
> Does this always ok ?

No, only

  let x = r and y = r in
  assert (x == y)

Neither r.b nor r.a are mutable, only r itself is.

     - Andreas

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

Re: [Caml-list] Semantics of physical equality

[Michal Moskal]

On Sat, Feb 28, 2004 at 10:40:34AM +0100, sejourne kevin wrote:
> A definition for mutable structures look ambiguous to
> me:
> 
> type test = 
> 	{
> 	mutable a:int;
> 	b:int
> 	};;
> 
> let r = {a=0;b=2};;
> 
> let x = r and y = r in 
> assert((x.a==y.a)&&(x.b==y.b)&&(x==y))
> ;;
> 
> Does this always ok ?

Yes, of course. The objects x and y are physically equal (which implies
physical equality of their fields).

However here x == y would fail:

   let x = {a = 0; b = 2}
   let y = {a = 0; b = 2}

while x.b==y.b && x.a==y.a would succeed.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?

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

Re: [Caml-list] Semantics of physical equality

[Michal Moskal]

On Sat, Feb 28, 2004 at 10:55:37AM +0100, Andreas Rossberg wrote:
> > type test = 
> > {
> > mutable a:int;
> > b:int
> > };;
> > 
> > let r = {a=0;b=2};;
> > 
> > let x = r and y = r in 
> > assert((x.a==y.a)&&(x.b==y.b)&&(x==y))
> > ;;
> > 
> > Does this always ok ?
> 
> No, only
> 
>   let x = r and y = r in
>   assert (x == y)
> 
> Neither r.b nor r.a are mutable, only r itself is.

But both r.a and r.b are ints, so it is always OK (== and = are the same
on ints).

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?

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

Re: [Caml-list] Semantics of physical equality

[Andreas Rossberg]

Michal Moskal <malekith@pld-linux.org> wrote:
> > type test =
> > {
> > mutable a:int;
> > b:int
> > };;
> >
> > let r = {a=0;b=2};;
> >
> > let x = r and y = r in
> > assert((x.a==y.a)&&(x.b==y.b)&&(x==y))
> > ;;
> >
> > Does this always ok ?
>
> Yes, of course. The objects x and y are physically equal (which implies
> physical equality of their fields).

No, because (x.a == x.a) is not comparing the fields themselves (you cannot
do that, fields are not first class), but the projected values. They may be
physically different. Consider:

  type r = {mutable a : float}
  let r = {a = 1.0}
  let b = x.a == x.a

This will deliver false.

> But both r.a and r.b are ints, so it is always OK (== and = are the same
> on ints).

That is what the current implementation does, but it is not guaranteed.

     - Andreas

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

Re: [Caml-list] Semantics of physical equality

[Michal Moskal]

On Sat, Feb 28, 2004 at 11:21:35AM +0100, Andreas Rossberg wrote:
> > But both r.a and r.b are ints, so it is always OK (== and = are the same
> > on ints).
> 
> That is what the current implementation does, but it is not guaranteed.

On integers and characters, physical equality is identical to structural
equality. [1]

It depends what you mean by ,,guaranteed'' though.

[1] http://caml.inria.fr/ocaml/htmlman/libref/Pervasives.html

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?

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

Re: [Caml-list] Semantics of physical equality

[Andreas Rossberg]

Michal Moskal <malekith@pld-linux.org> wrote:
> > > But both r.a and r.b are ints, so it is always OK (== and = are the
same
> > > on ints).
> >
> > That is what the current implementation does, but it is not guaranteed.
>
> On integers and characters, physical equality is identical to structural
> equality. [1]
>
> It depends what you mean by ,,guaranteed'' though.
>
> [1] http://caml.inria.fr/ocaml/htmlman/libref/Pervasives.html

You are right, I stand corrected. Int is a special case.

BTW, the manual speaks of "integers". Surely it only holds for plain type
"int", not for other integer types, like big_int, int32, does it?

     - Andreas

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

Re: [Caml-list] Semantics of physical equality

[Michal Moskal]

On Sat, Feb 28, 2004 at 11:45:53AM +0100, Andreas Rossberg wrote:
> Michal Moskal <malekith@pld-linux.org> wrote:
> > > > But both r.a and r.b are ints, so it is always OK (== and = are the
> same
> > > > on ints).
> > >
> > > That is what the current implementation does, but it is not guaranteed.
> >
> > On integers and characters, physical equality is identical to structural
> > equality. [1]
> >
> > It depends what you mean by ,,guaranteed'' though.
> >
> > [1] http://caml.inria.fr/ocaml/htmlman/libref/Pervasives.html
> 
> You are right, I stand corrected. Int is a special case.
> 
> BTW, the manual speaks of "integers". Surely it only holds for plain type
> "int", not for other integer types, like big_int, int32, does it?

Nope, these are boxed.

# let x = Int32.of_int 42;;
val x : int32 = 42l
# let y = Int32.of_int 42;;
val y : int32 = 42l
# x = y;;
- : bool = true
# x == y;;
- : bool = false

I mean it is not guaranteed, and moreover is not the case in the current
implementation.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?

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

Re: [Caml-list] Semantics of physical equality

[Michal Moskal]

On Fri, Feb 27, 2004 at 05:16:06PM -0600, Kevin S. Millikin wrote:
> In the current problem, it can save me a great
> deal of effort involved in generating temporary identifiers that are
> guaranteed to be unique, and in wrapping library data structures that I
> am unwilling to change in order merely to tag them.

type t = V of int ref

let t1 = V (ref 0)
let t2 = V (ref 0)

In this case you can assume t1 != t2. If it is not a sum type, but
record type, you can use record with at least one mutable field.

-- 
: Michal Moskal :: http://www.kernel.pl/~malekith :: GCS !tv h e>+++ b++
: When in doubt, use brute force. -- Ken Thompson :: UL++++$ C++ E--- a?

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

RE: [Caml-list] Semantics of physical equality

[Kevin S. Millikin]

On Friday, February 27, 2004 3:32 PM, Basile STARYNKEVITCH 
[SMTP:basile@starynkevitch.net] wrote:
    >> On Fri, Feb 27, 2004 at 02:29:50PM -0600, Kevin S. Millikin
    >> wrote:
    >>
    >> # V1(0) == V1(0);; - : bool = false
    >>
    >> V1's are different.  Is this guaranteed?

    >> What do you mean by guaranteed?

I mean ``guaranteed'' in the sense that separate calls to cons in 
Scheme
are guaranteed to produce objects that are distinct (according to eqv?
and eq?), or that a call to malloc in C is guaranteed to never return a
pointer that is the same as any other currently valid pointer in the
program (according to ==).

    >> Why would you want a guarantee that V1 0 is not physically equal
    >> to V1 0? I tend to think that making such an hypothesis is
    >> dangerous and wrong, even if the current implementation
    >> demonstrate it.

For the same reason that I occasionally rely on separate cons cells not
being eq? in Scheme ;).  In the current problem, it can save me a great
deal of effort involved in generating temporary identifiers that are
guaranteed to be unique, and in wrapping library data structures that I
am unwilling to change in order merely to tag them.

I realize that it would be dangerous and wrong to rely on them being ==
if the semantics of value constructors and == did not guarantee they
would be.  So I guess that's my question: "is it dangerous and wrong to
rely on separately constructed values being different according to 
==?".

-- Kevin

PS: Anyway, it looks like Michal Moskal has answered in the negative.
Neither behavior is guaranteed, which is an acceptable answer (though
not the one I was looking for).

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