Re: status of Ada STL?

[Dmitry A.Kazakov <mailbox@dmitry-kazakov.de>]

Russ wrote:

> 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.

I just gave you counter-examples. They show that even with primitive 
numerical types it is not so easy defend your point, because even they are 
not mathematical entities, but only inprecise models of those. Three 
involved types int, float and double model in the examples real numbers and 
oops, here you are. With user-defined types it becomes far worse.

Aside, you are trying to tie one langauge level the semantics of one 
operator with the semantics of another. This is a wrong way, which makes 
things more complicated for a programmer. It is wrong because SEMANTICS is 
a property of a program and not of the language the program is written in.
Interestingly is that Ada's design is on your side here, sigh. For 
instance, Ada tries to deduce inequality operator user-defined equality. It 
also tries to deduce assignment (":=") from copy-constructor (bitwise copy 
+ user-defined Adjust), etc. In my opinion it is a wrong way to do things.

> 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!

It is a good rule for 80% cases. Unfortunately it is not always possible to 
follow it. The real-world is more complicated than one might think. A pair 
examples:

1. A refers a hardware register. So A = 2, initiates I/O (read from A/D 
converter port Base + 2) and as a result A becomes 123!

2. A is a fuzzy set, then A==B is a pair of confidence factors, which 
cannot be tested in "if".

and so on and so far.

> 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.

The above is a wrong logic. Surely there is a very tight relation between 
"+" and "-" for some types, should then "+" be denoted as "-"? "Related" 
does not mean "same". I didn't claimed that assignment and equality have 
nothing to do with each other, I claimed that their semantcis does.

>> >> 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.

Sometimes I will. Consider UNIX-like processes. A meaningful assignment 
would kill the target and replace it with a clone of the source. A 
meaningfull equality would test if both processes are the same process.

>> 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.

It is a good practice. But agian, "*" should be [when possible] consistent 
with "+", which by no means forces us to use the same symbol for both.

>> >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?

The point is that though a set-theoretic equality might be defined, for 
some types it might appear unusable for them, like for floating-points or 
fuzzy sets. For other things it cannot be defined at all, yet alternative 
equality definitions might have sense for them. So there are situations 
when reasonable defined assignment and equality are not conformant with 
your proposition.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de