Question about checks for min and max values

[Nancy Palmquist]

Fairlight wrote:
> Simon--er, no...it was Nancy Palmquist--said:
> 
>>The correct mathematical definition for a IF line "eq" or slang "=" is 
>>equivalent.  Equivalent is not the same as Equal
> 
> 
> Given:
> 
> 1) You can use "=" in place of "eq" on an IF conditional segment
> 
> 2) The "=" sign is universally recognised as an EQUALS sign, not an
> "equivalence" sign
> 
> 
> Then:
> 
> The "=" sign is misconstrued and very loosely utilised in filePro, compared
> to the rest of the programming world.  
> 
> 
> 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.

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

> 
> 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?  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.
> 
> 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.
> 
> mark->
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 


-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com