Problem with INSTR()

[Fairlight]

On Thu, Feb 16, 2006 at 06:11:57AM -0500, John Esak, the prominent pundit,
witicized:
> There are 2 absolutely, undeniable reasons why the INSTR() function should
> NOT work the way you have  defined it.

I agree with you, John.  But your first example gave me an idea.  You won't
like the results, mate.  :(  Read one real quick summary of what you said,
and then look what I came up with.

> I have no problem with "l" and "L"
> being seen as the same. I even understand the expressions "l" and "L" can be
> expressed as chr("108") and chr("76") *respectively*... and if you were
> running *any* part of filePro other than INSTR(), the expression should be
> brought to its lowest common denominator so to speak and if it falls within
> the alphabet *should* be treated as equal with its upper or lower case
> counterpart. 

You gave me the idea.  Don't blame me for the results:

@once:chr("108") eq chr("76"):msgbox "Oh no!";end:

Much to my utter dismay, this actually worked.  That's -so- wrong.  That's
actually worse than INSTR being fouled.

I was hoping I was wrong, so I changed 46 to 47 and sure enough, it passes
on through as false.  I've checked this twice, flipping values so they
wouldn't match and then would.  I don't think I can deny reality.  I also
happen to think this is Dead Wrong[tm].

Here's my brief take on fP's handling of case insensitivity:

Case sensitivity is fine in a "non-specific" context.  If you're doing the
index matching, I can see it.  I suppose I can even live with "eq" working
the way it does.  But when you are comparing "absolute" values using actual
-functions- (especially when the functions are based on -specific- numeric
values), they should be case sensitive and exacting.  INSTR() and CHR()
are both subject to "absolute" evaluation constraints logically, in my
opinion.  They're not non-specific comparisons, they're actual functions
meant to test for a specific case.

Even -if- one could argue for INSTR() to act as it does, there is no way in
the world anyone will convince me CHR() should act as if a -specific-
numeric 108 is equal to a -specific- numeric 76.  I'm sorry, but those are
numerically specified, and I see -no- reason (other than fP trying to
maintain consistent, pervasive case-insensitivity) that these should be
equivalent.  It's a specific demand based on a numeric value, and there is
no way that 108 == 76, I'm sorry.  Converting it to the ASCII value L or l
and then REconverting it back to see if it's equivalent (or however it does
it internally...it makes the effort to be wrong) is so senseless, to my
mind.

Sorry.  This one blows INSTR() away.  I couldn't believe it when I saw it.

mark->