Semantics of Equals

[Bill Akers]

Jay R. Ashworth wrote:
> On Mon, Jul 25, 2005 at 02:50:43PM -0400, Nancy Palmquist wrote:
> 
>>>It may be what you expect from fP, but it's not what the rest of the world
>>>expects from a programming language in general.  That was Jay's whole
>>>point.  I agree with him.
>>
>>In early versions of filePro = was not allowed on an IF line.  It was 
>>allowed to be used instead of EQ in response to the programmers that did 
>>not understand the difference.  Filepro only responded to the community 
>>and their incorrect use of the = was accepted to make them happy.  I do 
>>not, however, see this as filepro admitting or accepting the change of 
>>meaning, it just did not cause any problem to allow it so they did.
> 
> 
> Fine, but that's a syntactical issue, and not germane.
> 
> 
>>>Attempts to rationalise its behaviour within fP are all fine and well, but
>>>they serve only as a bulwark for something that was (IMHO) incorrectly
>>>designated as interchangeable with something that should possess a
>>>different functionality entirely.
>>>
>>>In a conditional sense, equivalent and equals are not interchangeable in
>>>terms of result, as you so eloquently illustrated, and therefore should not
>>>be in terms of syntax.  That way leads to obfuscation and bugs.
>>
>>I don't think that filePro misunderstands the difference, it is the 
>>programming communitity that is not clear on the difference.  I disagree 
>>that filepro is wrong.
> 
> 
> You're welcome to disagree all you like.  You're also welcome to
> inspect the behavior of the "==" operator (the replacement for "=" as a
> comparison operator in many languages to avoid accidental assignment in
> a context where comparison is desired) in substantially *every* extant
> procedural programming language.
> 
> I believe you'll find it... instructive.
> 
> 
>>>That said, I doubt fP's syntax will change after 25+ years of being "wrong"
>>>on this topic.  That is -is- wrong will continue to remain a point of
>>>contention between those of us that regularly program in other languages as
>>>well, and those who live 95% or more in the fP-only coding world.
>>
>>I do not see anything wrong with filePro's behavior.  It behaves 
>>according to specification.  How is that wrong?
> 
> 
> It violates, rather severely, the Principle of Least Astonishment.
> 
> 
>>>So...let it go.  I disagree with its interchangeable implementation,
>>>but arguing the point won't change anything.  They're too busy adding a
>>>spell checker to be bothered with it, even if they cared about the real
>>>difference.  I doubt they would muck with backwards compatability anyway at
>>>this point.  Too much extant code relies on the faulty application of that
>>>operand for them to dare touch it.
>>
>>How can you hold filePro to a standard that was created, from scratch, 
>>after filepro was designed?
> 
> 
> Strawman.  That's not an accurate premise.
> 
> 
>>                            It is impossible to change the behavior of 
>>a package that was designed more than 25 years ago, to match a standard 
>>that has been determined since.  Think of the headaches that would cause.
> 
> 
> Were that actually the case, you'd be right.  Except for, y'know, *math*.
> 
> 
>>>It's not worth fighting over.  The facts speak for themselves to anyone
>>>that cares to observe them.  They don't need rationalisation.  So long as
>>>someone's aware of the fP-specific implications, they can work around it.
>>>That they shouldn't have to is probably Jay's point, and definitely has
>>>always been mine.
>>
>>I don't see this at all as a fight but an illumination of the behavior.
>>Consisentcy is always the issue and filepro consisently behaves the same 
>>way in this regard.  The rules are clear and well defined.  As Mark 
>>said, that should be enough.
> 
> 
> We're discussing, Nancy, *whether the language designer should have
> chosen those semantics for that particular token*, given the overloading
> that token contains from prior art, *substantially including* standard
> mathematics.
> 
> Equals means equals.  It doesn't mean "equals through the last
> character position of the shorter string".

Your argument would then be that mathematically '5' does not equal 
'5.00'?

> 
> And sloppy computer floating point implementations aren't germane here
> *either*, BTW...
> 
> Cheers,
> -- jra


-- 
William P. Akers                E-mail: billa at mgmindustries.com
                                 Web Site: 
http://www.mgmindustries.com/