From: Basile STARYNKEVITCH <basile@starynkevitch.net>
To: "Kevin S. Millikin" <kmillikin@atcorp.com>, caml-list@inria.fr
Subject: Re: [Caml-list] Semantics of physical equality
Date: Fri, 27 Feb 2004 22:32:29 +0100 [thread overview]
Message-ID: <20040227213229.GA2962@ours.starynkevitch.net> (raw)
In-Reply-To: <01C3FD3E.290EEEB0.kmillikin@atcorp.com>
[-- 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
next prev parent reply other threads:[~2004-02-27 21:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-27 20:29 Kevin S. Millikin
2004-02-27 21:32 ` Basile STARYNKEVITCH [this message]
2004-02-27 22:59 ` Michal Moskal
2004-02-28 9:40 ` sejourne kevin
2004-02-28 9:55 ` Andreas Rossberg
2004-02-28 10:07 ` Michal Moskal
2004-02-28 9:56 ` Michal Moskal
2004-02-28 10:21 ` Andreas Rossberg
2004-02-28 10:34 ` Michal Moskal
2004-02-28 10:45 ` Andreas Rossberg
2004-02-28 11:25 ` Michal Moskal
2004-02-27 23:16 Kevin S. Millikin
2004-02-27 23:48 ` Michal Moskal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040227213229.GA2962@ours.starynkevitch.net \
--to=basile@starynkevitch.net \
--cc=caml-list@inria.fr \
--cc=kmillikin@atcorp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox