Problem with INSTR()

[Brian K. White]

----- Original Message ----- 
From: "Fairlight" <fairlite at fairlite.com>
To: "Fplist (E-mail)" <filepro-list at seaslug.org>
Sent: Thursday, February 16, 2006 8:14 AM
Subject: Re: Problem with INSTR()


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

It's perfectly legitimate.
You and John are both in la-la land.

chr() is an expression.
expressions get evaluated into strings before the commands they are used 
with sees them
if you have foo("L") and foo("l") you know that foo() will treat them the 
same.

if you have foo(chr("76"))

foo() DOESN'T SEE THE CHR() !! IT ONLY SEES "L" !!

How friggn hard is this to understand?

Your attempt at a witty, cutting, display utterly fails to show stupidity 
anywhere except on your part.

We have known all along that as far as fp is concerned, If: "l" eq "L" 
resolves to "true"
the chr() version is no different. the If: doesn't see chr() it only sees 
the final result of what chr() and any other expressions evaluate out to.
chr("108") turns into "l", chr("76") turns into "L" and then the If: 
compares the "l" and "L" and it does not know or care anything about how 
those STRINGS came to be there.
Whethere they were entered as hard coded simple litterals, or whethere they 
were fields whose contents were "l" and "L", or whether they were variables, 
or whether they were the end product of some other expression, such as chr()

Don't feel bad, or do, as the case may be in a second, I once made 
essentialy the same mistake and you were a member of the list at that time 
and were part of that thread too.
I was amazed and dismayed to discover that "1" eq "12345" (or maybe the 
other way around, or both...)
Well, yeah it looks silly to the non programmer simplistic not especially 
logical or capable of abstract thinker, but I do get it now.
It's perfectly sane, it adheres to a rule. Moreover, it's even a _useful_ 
rule. The least common denominatoirs match and for the types of applications 
and types of programmers fp was designed for, that is actually the most 
common desired result. In other contexts, such as nuclear physics modelling, 
the most often desired result is full and exact matches and only those. For 
the home grown doctors offices and pizza shops and girl scout bake sales 
customer files and the retail store inventory list, etc... It's more useful 
that "pre" DOES match "Pressure Regulator 30lbs 1/2in brass"

It's like you are both determined to be blind because well you started and 
now you have to stick with it or be wrong.
GAHHH! Never!!!!!

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!