|
![](/i/fill.gif) |
>> (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
|
![](/i/fill.gif) |