Problem with INSTR()

[Kenneth Brody]

Quoting John Esak (Thu, 16 Feb 2006 06:11:57 -0500):

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

Correct, in ASCII (the only character set filePro currently runs on),
CHR("76") is a capital "L".  I never said otherwise.

[...]

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

I never said that the value returned would be a lowercase "l".  What I
did say is that filePro, being case-insignificant, compares capital "L"
and lowercase "l" equivalent.  By that same reason, CHR("76") and the
lowercase "l" compare equivalent as well, as there is no difference
between CHR("76") and a capital "L".

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

Why should INSTR() be any different than the rest of filePro?  If you
were to test if "Smithington" contains "SMITH", filePro would return
"true", and you would expect it to return "true", correct?  So, why
would you expect INSTR() to tell you that "Smithington" does not
contain "SMITH"?

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

Well, I'll have to dispute the "undeniable" qualifier in the above.

> 1) I understand that in filePro, Windows (from old DOS days) is
> case-insensitive in 99% of what it does.

Well, I'm not sure what filePro functionality has to do with Windows
case-insensitivity, beyond filePro's use of filenames.  But, I'm
listening...

> I have no problem with "l" and "L" being seen as the same.

Okay...

> I even understand the expressions "l" and "L" can be expressed as
> chr("108") and chr("76") *respectively*...

Correct.  (Again, for the nit-picking, we're talking ASCII here, which
is the only character set filePro currently runs on.)

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

Okay.  Though I don't understand "any part other than INSTR()".

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

But, INSTR()'s function is _not_ to "return a particular character".
The purpose of INSTR() is to find a _string_ (for the nit-pickers, my
use of "string" does not mean "C's nul-terminated 'string'") within
another string.

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

Well, technically, there are _two_ square roots for any given number.
filePro returns the positive one.  (I was a math major, so some things
are burned into ROM at this point.)

:-)

I should also point out that filePro's SQRT() function will return a
value for negative numbers, as it actually returns the square root of
the parameter's absolute value.  I suppose you could claim that the
SQRT() function is, therefore, "broken".

> 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. :-)

While I can see the usefulness in adding an option to INSTR(), or making
a new function, to make it case-sensitive, I still have to disagree with
your login that INSTR() *must* be case-sensitive, despite the rest of
filePro being insensitive.  As I said, if the COntains relationship is
case-insensitive (as you yourself said you would expect it to be), then
why should INSTR(), which is equivalent to COntains, except that it also
returns _where_ it is contained, be case-sensitive?

Why should:

    "Smithington" CO "SMITH"

be true, while:

     INSTR("Smithington","SMITH")

return zero?

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

Correct.  If you need to do a case-sensitive search within a string,
you need to do something in addition to INSTR().  The same holds true
for any other string comparisons within filePro, with the obvious
exception of COMPARE(), which was written explicitly to _be_ the
exception.

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

Yet you don't think that INSTR() should find "Smith" if you search for
"SMITH".  Why is that so?

> This is *not* a use of a function that is purposely designed to
> retrieve a particular character,

I think you have misunderstood the purpose of INSTR(), as you keep
mentioning that it is to search for a "character", and not a "string".

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

When used as a comparision operator, they are the same.  Of course, you
can also have a dummy field named "eq", and you can use "=" as an
assignment operator as well.  But, as a comparison operator, they are
always the sams.

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

Well, it is when the function is "search one string for another one".
Why should its search be defined differently?

(Though my "why not just make all of filePro case-insignificant" was
meant to be rhetorical.)

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

Again, I agree that it may be useful to enhance the functionality to
include case-sensitive searching, but that should definitely not be the
default, as that would break the case-insignificant paradigm used
everywhere in filePro.  (Again, with the obvious exceptions of
filenames on case-sensitive file systems, and the COMPARE() function,
whose sole purpose is to do a case-sensitive compare.)

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com