Immutable and Mutable Types

[Ben Finney]

Bernard Lim <bernard at blimyk.org> writes:

> <paraphrase>
> Depending on implementation, for immutable types, operations that
> compute new values may or may not actually return a reference to any
> existing object with the same type and value, while for mutable
> objects this is (strictly)? not allowed.
> </paraphrase>
> 
> Using the example given in 3.1, how do I verify that this is true
> pertaining to immutable types?

You don't. By the language definition, it's entirely up to the
implementation whether *and when* to do this.

So, even if you find a particular session that does this, there's no
telling whether it'll stop happening at some future session using
*exactly the same inputs* -- and, if it did change, that would also be
entirely within the definition of the language.

If something in a language specification says "this set of conditions
leads to undefined behaviour", or "this aspect is implementation
defined", then *absolutely any behaviour* that fits the rest of the
definition is allowed, even if that results in non-determinism from
the programmer's perspective.

In short: Don't ever rely on such behaviour labelled with these "may
or may not" phrases, even if you run some tests and appear to get
predictable results.

-- 
 \             “The power of accurate observation is frequently called |
  `\        cynicism by those who don't have it.” —George Bernard Shaw |
_o__)                                                                  |
Ben Finney