or: \/ etc

[Brian Rice]

What's happening is that, inside blocks, the bytecode compiler is 
optimizing this into low-level control-flow codes that don't (and right 
now, can't) check the type of the arguments. (see generate:on:from: 
methods for #/\, #\/, #and:, #or: in 
src/mobius/vm/interp/compiler.slate).

Note that all of these expressions are errors when evaluated outside of 
blocks.

We'll take a look at adding some safety features to the VM for it, or 
somehow for the compiler, but in the mean-time, just don't use 
non-Boolean arguments on logical conjunctions, please.

On Mar 16, 2005, at 5:35 PM, John Leuner wrote:

> Please examine the code below and help me understand what's going on
> here?
>
> Why do I get different results?
>
>
> x@(Root traits) checkMe: a against: b
> [
>   (a)
>     \/ [b /\ ['c']]
> ].
>
> x@(Root traits) checkMe2: a against: b
> [
>   (a)
>     or: [b and: ['c']]
> ].
>
> Slate 19> checkMe: Nil against: False.
> False
> Slate 20> checkMe2: Nil against: False.
> True
>
>
> John
>
>
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/