Problem with INSTR()

[John Esak]

> Well, assuming that you meant to put quotes around the lowercase "l"
> on the first line, you will see that the first "if" is true, and the
> "Ken is right..." message will be displayed.
>
> I guess it depends on your definition of "the desired results".  :-)
>

No, it does not depend on any definition I, or you, might make. The value
chr("76") is equal to "L" not "l". This discussion would be over if you
think otherwise. I can't debate this with you if you are just going to make
a statement like this and not adhere to the facts. If a person were to look
on the ASCII chart for the value of chr("76"), there is simply NO way, ever,
that they would come up with "l". To just say because you want it to work
that way and define it that way to gain your "desired results" does not hold
water. filePro can, of course, set any rules, any definitions for the
desired results... and I agree in 99.9% of the *rest* of filePro,
case-insensitivity is a good and "desirable" result. Even for the general
compares on processing tables, it is a good an desirable thing. For a
function specifically designed to return a particular field within another
field, no. In the same way that grep won't find "Smith" if it only comes
across SMITH... unless you flip the default option, so it should be with
filePro. Why? Because...

There are 2 absolutely, undeniable reasons why the INSTR() function should
NOT work the way you have  defined it.


1) I understand that in filePro, Windows (from old DOS days) is
case-insensitive in 99% of what it does. 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. This is the way filePro has worked forever, and *this* is
governed exactly as you say, "depends on your definition of 'the desired
results'". Correct, no disagreement. HOWEVER, and notice that HOWEVER in
this situation is an EXCEPTION to the framework I have just *defined*... in
the case of a function whose *specific* and *only* task is to return a
*particular* character, the function should return that character specified
and *only* that character specified. It is simply the purest form of the
table lookup this function has to perform... with NO additional definitions
or restrictions on the lookup. Adding ng more to the definition corrupts the
stated purpose of the function. If you build a SQRT() in filePro, it had
better come up with what the only possible value is for the given number.
Just because filePro defines that indexes and generic string compares should
ignore case, it does not mean that a function whose sole purpose is to look
for specific characters should *also* ignore case. One does not logically
follow from the other. In fact, this would be a perfect representation of
the spurious kind o non-equator that rules the PC community. :-)

2) By defining the function as you have, it "cripples" the function, in that
it can *never* return the correct character for 26 of the characters in the
table it is using. In other words using the function alone, there is no way
to return the capital letters if you want one of them, you have to go
outside the function to do this. It would be like designing a function that
has the purpose of returning the value of the addition of any two
integers... and then setting the range of integers from 1 to 6. The function
would work, but you have purposely designed it to be crippled and not fully
*functional*. (sorry, couldn't resist... :-)  In the case of an index
lookup, or 99% of the other features and functions in filePro, I fully agree
that you *want* to define for the case-insignificance of letters. The
overwhelming majority of operations (and people running the operations) want
the function to work that way. You search for Smith or SMITH, and you *want*
it to return either occurrence. This is *not* a use of a function that is
purposely designed to retrieve a particular character, so because you need
this functionality, generally, it does not mean you should design a function
that has a completely different use to act in this way. It would be like
saying that because having "eq" and "=" on an IF condition mean the same
thing, that everywhere else in filePro "eq" and "=" should act this way.
Ridiculous, no?  But that is what you are arguing. If we went with this, how
would you ever assign a value to a variable?


> Besides, it certainly would give the INSTR() function a lot more depth.
> >
> > So what would be wrong with PFINSTRWORKSLIKEJOHNWANTSITTO=ON  ??
> >
> > and keep the default OFF if you must. :-)
>
> Why not just make all of filePro case-significant?  Why should INSTR()
> be an exception to the rule?

This does not require any real answer. Because I think a function designed
to return a particular value is *not* "all of filePro" it is a particularly
designed function, and in this specific case, I think INSTR() should be
case-significant. Or at worst case, have an environment value and/or option
to work either way... with the default to case-significant actually.

John