browse keys (@bk)

[Fairlight]

Is it just me, or did John Esak say:
> 
> By this logic, Mark, you would also disagree with Mr. Bourne (and a hug host
> of other language designers)... Unfortunately, or fortunately, the use of

Actually, in most Bourne-esque shells, [ is actually an external to
/usr/bin/[ which is a symlink to /usr/bin/test.  That's been my experience.

> any operator (like eq for example...) is just a matter of explanation and
> convention... in other words, *this* is how it works here... and this is how
> it works somewhere else... For Jay, or anyone, to say filePro is doing it
> *wrong* is (I'm sorry to say) is just ridiculous... It is just another
> attempt to start and argument where there is no reason for one. To use your
> comment above, the way "eq" works in the shell would be *wrong* also, but I
> don't see you or Jay writing to AT&T, Berkeley or Linus...
> 
> $  num1=2
> $  num2=3
> $ [ num2 -eq num1 ] && echo "All eq's must work the way Jay says..."

But that's not (from my interpretation) what he's saying.  "2" and "3" (in
filePro parlance, quoted, so we're sure they're actually numbers, not
fields), are always going to differ, of course.

AFAIK, Jay was talking about -strings-.  'test' = 'TeSt' will test negative
in /usr/bin/test.  I just checked.  And the operator is different there as
well--it's an "=", not "eq", which is reserved for numerical comparisons in
Bourne/test.  I don't quibble about what it's -called-.  But your saying
that I would say 'eq' is "wrong" in fP is not entirely accurate, based on
your assumptions, precisely because Bourne's "eq" operator is numeric-only,
not string.  But fP makes no such distinction, and both are handled with the
same operator.  However, even reduced to numerical constructs (say,
converted to hex, decimal, whatever), 'test' will not equal 'TEST' with the
case difference.  And by default, even in Bourne, that tests as it
should--in the negative.  fP tests in the positive by default, requiring
you to use COMPARE().  The only instance in which they should actually test
literally equivalently is after a soundex conversion, I should think.

-All- I'm saying is that the default of most places (including Bourne on
stock SCO 5.0.6, I just tried) is a case -sensitive- comparison on
-strings-.

If someone was talking about integer comparisons, I didn't even -catch-
that.  I'm talking purely about strings.  Now since Ken already clarified
the ability to use COMPARE() directly in a condition line, I see it as a
non-issue for anyone using 4.5 and up.

> was adopted as the best design at the time. My issue with Jay's statements
> that it is wrong... well, I can't say it any plainer, can I. He just wants
> an argument where really is nothing to argue about. It is not the eq that is
> "wrong", it is his statements about it.

Well, it's certainly unexpected if you come from other languages--even as
archaic as BASIC.  Since COMPARE() is fully usable in conditional
statements (I wasn't aware it was), I also see no actual argument.  I would
simply expect, as a newcomer to fP if I were one, that case would be
accounted for.  This isn't the case, but one can easily work around it--at
least since 4.5.

I don't see it as a big deal, and I've -no- wish to get between you two on
this.  I'm simply saying it behaves the opposite of the default of most
environments and languages--including the Bourne you brought up, if you
apply it to strings, which is what I though the initial argument was.
Consider:

#!/bin/sh

if ([ 'test' = 'TeSt' ])
then
     echo "Equal."
fi
exit

That -will- test false.  They are not equal.

Like I said, it's not a substantial issue if it can be worked around.
But if "eq" is taken to be a -universal- operand for "equality" of two
terms, it should be extended towards strings a literally as it is to
numerals.  They're either identical or they're not.  I'm citing it as a
concept, not as anything inherently wrong with fP.  I just believe -any-
language should treat them literally without implicit case insensitivity.
If perl disregarded case, I'd take issue with it there as well, believe
me.  

There's something inherently problematic in my eyes with data being
manipulated without express intent.  And essentially, a default operator
-probably- should not manipulate the data internally...which is what it
does when it disregards case.  You should have to take special pains to
achieve data manipulation, via use of a separate operator.  Too many
problems come from doing things automatically and people not being aware of
the fact until it's too late.  That goes for just about anything complex,
from computers, to cell phones, to anything.

Of course, if it's -documented- as such (and I believe it was, as far back
as I started in 4.1), then there's zero cause for serious debate.  Then
it's a purely academic discussion of design principles and decisions, and
that's largely subjective, within some reasonable generally accepted
boundaries of convention.  I won't say fP is "wrong", I'll just say it
defies convention.

Actually, since we're talking about operators, -is- there any difference
between using "eq" and "=" on a conditional line in fP?  I always read the
manual in the 4.1 days as saying you -always- use "eq" in If lines and "="
for assignments.  I've seen people use "=" on If lines though, and I wonder
if there's a functional difference, or if it performs the same test.  I
wouldn't mind a definitive answer after all these years.  :)

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html