Strings and boolean operators

[zarqon]

I discovered recently that the ASH interpreter sometimes allows strings to be used with boolean operators, but only if a string is specified on the left side of the operator.

> ash ("foo" && "bar")

Returned: false

> ash ("foo" && "foo")

Returned: false

> ash ("foo" && true)

Returned: false

> ash (true && "bar")

Cannot apply operator && to true (boolean) and bar (string) (zlib.ash)
Returned: void

> ash string foo; if (foo) print("bar")

"if" requires a boolean conditional expression (zlib.ash)
Returned: void

> ash ("a" || "b")

Returned: b

> ash ("c" || "b")

Returned: b

Can anyone explain what's going on here? What strings would need to be supplied for A and B to make (A && B) return true? What operation is (A || B) actually performing?

Or, conversely, is this a bug?

 

[Catch-22]

Bug is kind of a strong word, but you shouldn't be using binary operations on strings (and it would be a nice feature if KoLmafia didn't let you).

Edit: Just to answer your questions...

What strings would need to be supplied for A and B to make (A && B) return true?

This will never return true, the first string is interpreted as int 0 (or false), which means we can discard whatever is on the right hand side and return false immediately.

What operation is (A || B) actually performing?

Again, the first string is interpreted as int 0, as the first section is considered false KoLmafia then evaluates whatever is in the right hand side and returns that instead (seems an odd way to handle xor but it obviously works for boolean expressions).

 

[zarqon]

Thanks Catch-22. I agree, I'd prefer if mafia disallowed this, particularly as in practice it would be utterly pointless. Will make a Feature Request.

I recently changed a boolean variable in BatBrain to a string and used verify to help me locate all instances of the variable that I needed to edit (not sure really why I didn't just use the Find function of the editor). Surprisingly, after a few changes, it verified, despite several instances remaining! All of those instances were (stringvar || otherchecks). If I hadn't then used Find because I knew there were more instances, those instances may have remained, leading to undesirable behavior (extremely undesirable in this particular case).