FIND - inconsistent arg checking

[Siskin-Bot]

Submitted by: Sunanda

FIND will helpfully stop me looking for string in binary:

>> find to-binary "aaaAAA" "A"
** Script error: values must be of the same type.

But it'll have a go at finding a binary in a string:

>> find "aaaAAA"  to-binary "A"
== none

Ditto REPLACE
And looking for CHAR in BINARY.

---

^{Imported from: CureCode [ Version: alpha 76 Type: Issue Platform: All Category: Native Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#1159}

Comments:

Rebolbot commented on Jul 27, 2009:

Submitted by: BrianH

FIND string! does a FORM to its second argument if it is not a string (except for tag!, which it does a TO-STRING on). Here are some experiments:

>> to-string to-binary "a"
== "a"
>> form to-binary "a"
== "#{61}"

>> find "a" to-binary "a"
== none  ; R2 FIND here == "a"

R2 FIND string! does an implicit TO-STRING of binary! - good, but perhaps ASCII-centric.

>> find form to-binary "a" to-binary "a"
== "#{61}"

R3 FIND string! does implicit FORM of binary! - weird, but it makes sense because the binary might not be UTF-8 encoded. And it's consistent with its treatment of other types:

>> find "0" form 0
== "0"
>> find "0" form #"0"
== "0"
>> find "0" form [0]
== "0"
>> find "0" form make vector! 1
== "0"

But FIND string! is broken for tag! - apparently it uses the raw string data of other string types when (at least for tag!) it should do a FORM (written this way because of CureCode tag screening):

>> find form to-tag "a" to-tag "a"
== "a>"  ; should be at head

FIND is an action! in R3, and actions are handled by different functions depending on the type of their first argument. So inconsistency is not in itself a bug between actions of different types, but might be considered a bug within a single action (as it is with FIND string! tag!).

Considering that, we have two tickets here: A bug for FIND string! tag! (#1160), and a wish for FIND binary! (#1161). I'm going to have to change this ticket to an Issue and split off those to separate tickets (#1160 and #1161, respectively).

---

[Oldes]

I'm closing it as there should be separated requests for various combinations.