why () is () and [] is [] work in other way?

[Nobody]

On Mon, 23 Apr 2012 10:01:24 -0700, Paul Rubin wrote:

>> I can't think of a single case where 'is' is ill-defined.
> 
> If I can't predict the output of
> 
>     print (20+30 is 30+20)  # check whether addition is commutative print
>     (20*30 is 30*20)  # check whether multiplication is commutative
> 
> by just reading the language definition and the code, I'd have to say "is"
> is ill-defined.

If anything is ill-defined, then it's "+" and "*", i.e. it's unspecified
whether the value which they return is a unique object or a reference to
some other object.

More accurately, the existence of "is", "is not" and "id" cause many other
constructs to have "ill-defined" behaviour.

>> "a is b" is true iff 'a' and 'b' are the same object. Why should 'is'
>> lie to the user?
> 
> Whether a and b are the same object is implementation-dependent.

And what's wrong with that? If you want a language which precisely
specifies all observable behaviour, you're going to end up with a rather
useless language. For a start, it can't have a time() function. For
similar reasons, you can't have networking or any form of preemptive
concurrency (which includes any form of inter-process communication on an
OS which uses preemptive multi-tasking).