Re: status of Ada STL?

[18k11tm001@sneakemail.com (Russ)]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<ibt0hu4fdr9ql5duvgogp9iv6vf57kqgr7@4ax.com>...
> On 18 Jun 2002 22:32:12 -0700, 18k11tm001@sneakemail.com (Russ) wrote:
> 
> >Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> wrote in message news:<aemvpd$8dojl$1@ID-77047.news.dfncis.de>...
> >> Russ wrote:
> >> 
> >> > Immediately after the statement "x=3" executes, it becomes true in the
> >> > mathematical sense, which is why it makes sense.
> >> 
> >> Nope. Consider C++ having user-defined type conversions. It is very easy to 
> >> write a program in C++ that
> >> 
> >> SomeClass x;
> >> 
> >> x=3;
> >> if (x==3) // false
> >
> >I should have been more specific. For any instance x of a built-in
> >numerical type, the statement "x=3" becomes true in a mathematical
> >sense immediately after it executes. (If I am wrong, please provide a
> >counter-example.)
> 
> 1. From ADT point of view there is no difference between numerical,
> built-in or whatsoever types and other types. There are good reasons
> why it should be so.
> 
> 2. Try [C is a funny language!]:
> 
>    int x;
> 
>    x=1.5;
>    if (x == 1.5) // false
> --------------------------------
>    float x;
> 
>    x = 1.00000001;
>    if (x != 1.00000001) printf ("oops!\n");

All you've shown here is that assignment does not always work as
expected in C. I agree that a non-integer shouldn't simply be
converted an integer with no warning, but that's a completely separate
issue from the semantics of assignment. Had those assignments worked
as the programmer presumably intended them to, the tests would have
evaluated to true.

Let me postulate a rule of good programming practice, and you can let
me know if you agree with it or not. If I define an assignment
operation for a particular type or between any two types, and if I
also define an equality test between them, then immediately after the
assignment is executed for instances of those two types, the equality
test should evaluate to true. For example:

type1 A;
type2 B;
...
A = B;
if ( A == B ) ... // true or you goofed somewhere, dude!

Note that it will not always make sense to define the assignment
operator and/or the equality test operator for every possible
combination of types, and my rule applies only when they are both
defined. Unless you disagree with this rule, you must agree that there
is indeed a very close relationship between assignment and equality
testing, and your earlier claim that they have "nothing to do" with
each other is nonsense. And so is the notion that "=" should not be
used for assignment.

> >> In fact assignment (semantic of) has nothing to do with equality. You may 
> >> have incomparable objects which can be assigned. You may have comparable 
> >> objects that cannot be assigned. You may have objects which have several 
> >> different semantics for assignment (deep/shallow copy/reference) and 
> >> equality (distance/set equality etc).
> >
> >That's really all irrelevant to the main point here. If you have two
> >different objects A and B of the SAME type,
> 
> What is for two types to be SAME? It is not an easy question as one
> might think.
> 
> > then
> >
> >someclass A, B;
> >A = B;
> >if ( A == B ) ... // better be true!
> 
> But then if you would insist that it should be so in strict
> mathematical set-theoretic sense, I would derive from that, that also
> 
> A'Address = B'Address -- better be true!

In C++ you can define the "==" operator for any two types any way you
wish. Your particular definition depends on the problem you are trying
to solve, of course. But in most cases you probably would not be
testing whether the two objects are actually one and the same object.

> If A and B are SAME then there should be no way to distingush them.
> From programming point of view it has in most cases no sense [however,
> see LSP]. "==" is not equality it only models one of many possible.

But I contend it should at least be consistent with your assignment
operator for the type or types it applies to.

> >If this doesn't evaluate to true, you have goofy code. Yes, I realize
> >that asignment can be overloaded in C++ in all kinds of ways, but
> >that's really a distraction. Your claim that "assignment has nothing
> >to do with equality" is just plain wrong. Nothing to do with it? Give
> >me a break!
> 
> You can start to define what is equality of two fuzzy sets. What is
> equality of two floating-point numbers. What is equality of two remote
> servers. What is equality of two people. Go on.

As I'm sure you well know, good programmers rarely test for exact
equality of two floating point numbers. And if you can test for exact
equality of two fuzzy sets, how "fuzzy" can they be? Perhaps I am
missing your point here. Do you have one?