Version française
Home     About     Download     Resources     Contact us    
Browse thread
RE: [Caml-list] Semantics of physical equality
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Kevin S. Millikin <kmillikin@a...>
Subject: RE: [Caml-list] Semantics of physical equality
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