>> (I know  some people use the triple-line symbol for this though.)
>>
>> The main confusion is between assignment and equality, generally. 
> 
> That is why most languages have separate symbols for both meanings (and 
> why I am advocating imperative languages without assignment).

Heh. How many C programs fail because people use "=" instead of "=="?

(Most strongly-typed languages manage to catch this mistake. C is 
deliberately designed to make this mistake a valid program construct. 
Friggin' weirdos...)

>> Or, in mathematics, between a test for equality and a statement of 
>> equality.
> 
> Can you give an example of that?

If I say "x = sqrt(y/z)", do I mean that x *is* equal to this RHS? Or is 
it an equation that must be solved by *making* x equal to the RHS?

Similarly, this fragment can appear inside a statement, such as "f(x) = 
3 if x = sqrt(y/z), otherwise 9". In that case, the "x = sqrt(y/z)" part 
is clearly a conditional test.

So "x = sqrt(y/z)" can mean:
- x *is* equal to this.
- you must *make* x equal to this.
- please *test* whether x is equal to this.

As you point out, there's also the distinction between "x just happens 
to equal this thing" and "x is defined as being this thing".

>>> ** See also the concept of '=' in OO languages. Are two objects the 
>>> same if all fields are the same?
>>
>> You would first have to define the concept of fields being "the same". 
>> ;-)
> 
> spot on

Hence deep-equal and shallow equal, value-equal and reference-equal.

>> Fortunately, in a pure functional language, the question becomes a lot 
>> simpler.
> 
> Not so sure about that.

If data cannot be altered, it is not possible to distinguish between two 
objects which are reference-equal and two objects which are merely 
value-equal.

The question of deep/shallow still arises, and you still have to decide 
whether you mean "identical" or just "equivilent" (which will generally 
depend on what the data *means*). But you don't have to worry about 
reference-equal any more, which is a significant simplification.

(Until you start dealing with mutable data. In that case, since equality 
is a pure operation, it is natural that you should consider only 
reference-equality. Indeed, Haskell's type system *demands* this.)

> Anyway even if that would be the case it doesn't 
> solve the 'problem' that in real life you have multiple views to look at 
> an equation.

Indeed.

Post a reply to this message