Semantics of Equals (was: Re: Question about checks for min and max values)

[Jay R. Ashworth]

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

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

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

      "...the rough cannot be mean and the love cannot be true, and that's
      as wise as I can get at 10 o'clock in the morning."
      	-- Bill Shatner, on being an anti-hero.