Find/any doesn't seem to find strings in blocks..
[1/5] from: bhandley::zip::com::au at: 20-Aug-2000 11:35
I would have expected this to work. Am I missing something?
>> find/any ["my-string"] "my*"
== none
Brett.
--
>> my-rebol-stuff
== http://www.zipworld.com.au/~bhandley/rebol
[2/5] from: etcha:gsat:au at: 20-Aug-2000 12:00
whats wrong with:
>> blah: "my-string"
== "my-string"
>> blah: parse blah "-"
== ["my" "string"]
>> if find blah "my" [print ["yes"]]
yes
>>
its not what you want, but you cant search the string for something thats
not there,
eg "my*" :)
etcha
[3/5] from: rebol:techscribe at: 19-Aug-2000 21:44
Hi etcha,
>> help find
[...]
/any -- Enables the * and ? wildcards.
[...]
Case 1:
>> string: "xdefgjkljyjkljweruiouz"
>> find/any string "y*z"
== "yjkljweruiouz"
Case 2:
>> block-with-string: reduce [string]
== ["xdefgjkljyjkljweruiouz"]
>> find/any block-with-string "y*z"
== none
Should find's behavior be the same in both cases?
At 12:00 PM 8/20/00 +1000, you wrote:
>whats wrong with:
>>> blah: "my-string"
<<quoted lines omitted: 24>>
>>== http://www.zipworld.com.au/~bhandley/rebol
>>
;- Elan [ : - ) ]
author of REBOL: THE OFFICIAL GUIDE
REBOL Press: The Official Source for REBOL Books
http://www.REBOLpress.com
visit me at http://www.TechScribe.com
[4/5] from: bhandley:zip:au at: 20-Aug-2000 23:45
Hi Elan,
Good question. I assumed one sort of behaviour but it is not necessarily
obvious is it?
Having thought on it a little I think the /any refinement should be
activated for the block situation or the help/documentation changed to
indicate it will not work. My preference is for the former since we should
get those other great refinements as part of the bargin.
I suspect that the behaviour should not be the same in both cases as the
cases are of different types.
Since Find is defined as "Finds a value in a series..." - its behaviour
should depend on the values of the series it is given.
The values of a string are characters so Find returns us the string with the
current index of the string set appropriately - resulting in a part string.
So, I suggest that it makes sense that the result of the find on a block
should be the block with the current index set appropriately, as it does
now, but with the /any refinement enabled to influence the matching.
Any comments?
Brett.
[5/5] from: bhandley:zip:au at: 21-Aug-2000 0:19
Hm. Which means I want a consistent behaviour (setting the index
appropriately according to the value found) even if it looks different (one
returns what looks like a part string - the other returns what looks like a
part block, not a part string).
Brett.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted