INSTR a fine keyword that works as it has been projected!

[TempodiBasic]

Hi guys
I like your attention about INSTR features so I have thought that it is better to begin another thread instead to occupy that of Terry about QB64sourcecode.com.

Here our wiki that shows us the peculiarities of INSTR
https://www.qb64.org/wiki/INSTR

INSTR (startSearching%, InWhatStringtosearch$, WhatwesearchString$)

INSTR returns 0 if an empty baseString$ is passed, and returns 1 with an empty searchString$

the second affirmation is not 100% true as demonstrated by Bplus's code here
https://www.qb64.org/forum/index.php?topic=2487.msg117466#msg117466
and also this affirmation is not true as demonstrated by  the above linked code

The start% position had to be at least 1 or greater when used or there will be an Illegal function call error. In QB64, a start% value of 0 or negative is interpreted as 1 and doesn't generate an error.

INSTR returns 0 when it searches before the beginning position of the string in which it searches, and after the end of the string in  which it researches

but following the thinking of Steve to explain better why the original autors of STRING have choosen to return 1 if you search a nullstring into the baseString$ (InWhatStringToSearch$)

Code: QB64: [Select]

1. a$ = ""
2. b$ = "abcd"
3. c$ = a$ + b$
4. PRINT INSTR(c$, a$)

but if we append as 6 & 7 lines

Code: QB64: [Select]

1. PRINT LEN(c$)
2. PRINT LEN(a$)

we realize that nullstring is something for INSTR and nothing for LEN and PRINT. Its dual aspect let me remeber the electron in atom and the principle of undetermination of Heisenberg

I stress here that I write to talk and not to want to change INSTR, it's a QBASIC statement that QB64 emulates very well.
here code to explore these features of INSTR, a good keyword with a little black side...

Code: QB64: [Select]

1. PRINT "Nullstring at the start position of a basestring "
2. a$ = ""
3. b$ = "abcde"
4. c$ = a$ + a$ + a$ + b$
5. ' it is added 3 times a nullstring at the beginning of the string c$
6. ' now teorically c$ has gained 3 more characters (of nullstring)
7. ' they are not visible on printing but they are here.
8. ' so LEN of c$ now should report 8 and not 5 as at beginning
9. ' moreover going from 1 to 8  I must always get the result >0
10. PRINT "a$ = "; a$; "-"; "b$= "; b$; " "; "c$= "; c$
11. PRINT LEN(a$), LEN(b$), LEN(c$)
12. FOR a = 1 TO 8
13.     PRINT " Result  position        basestring   searchstring"
14.     PRINT INSTR(a, c$, a$), a, c$, a$
15. NEXT

I find the situation similar to the answer that you can give at this question "How many 0 are in the digit 1?"
if your approach is mathematical the question becomes "How many 0 are added to digit 1 to let 1 be itself?"
The answers -infinite , 0, + infinite  of zero value are all correct because all these operations let  1 be itself
if you approach is rapresentational the question becomes "How many 0  can be written before and after 1 to let 1 be itself?"
The answers seem equal to the previuos question, In fact 1 = 01 = 001 = 0001 = 0001.0= 00001.0000 etc etc etc

Thanks to read and to talk

[bplus]

I look at it this way, you can always find nothing in something but you can and/or can't find nothing in nothing :)

[TempodiBasic]

Hi Bplus
thanks to show  another point of view that is condivisible, also if a part of my brain continues to say finding nothing in something is equal to not finding  in something, but this is only a semanthic different approaching to the situation.
I am not able to imagine what has been the goal to build a function that can search nothing in something,  but surely in the mind of the authors there was an use of this feature of INSTR.

[SMcNeill]

Hi Bplus
thanks to show  another point of view that is condivisible, also if a part of my brain continues to say finding nothing in something is equal to not finding  in something, but this is only a semanthic different approaching to the situation.
I am not able to imagine what has been the goal to build a function that can search nothing in something,  but surely in the mind of the authors there was an use of this feature of INSTR.

For the QB64 authors, the use was "compatibility with QB45 usage.  Now why the guys who wrote QB45 had it the way they did, you'd need to ask them.  :P

[TempodiBasic]

Hi Steve
I agree totally with you and
sorry for my bad communication
when I have written authors I was thinking about who designed QB45 that QB64 duplicates very good.

[bplus]

Now why the guys who wrote QB45 had it the way they did, you'd need to ask them.  :P

Well I am glad they didn't treat it like a division by zero error with complete shut down of execution.

Maybe it is a code joke because it is funny.