or: \/ etc

Tim Olson tim at io.com
Thu Mar 17 15:31:47 PST 2005

On Mar 17, 2005, at 9:33 AM, Brian Rice wrote:

> 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).

Interesting.  But that optimization only appears to happen when the 
second argument is  a block.  However, when I evaluate:

	Nil \/ Nil

I get "True", rather than a "method not found" error.

The method being applied seems to be:

_@(Boolean traits) \/ _@(Boolean traits) [True].

as determined from this:

[ | m1 m2 m3 |
m1: (#\/ findOn: {True. True}).
m2: (#\/ findOn: {Boolean. Boolean}).
m3: (#\/ findOn: {Nil. Nil}).
{m1 == m2. m1 == m3. m2 == m3}] do.
=> {True. True. True}

This also appears to happen for small integers, as well as Nil.  So how 
do Nil and the small integers match the (Boolean traits) trait?

	-- tim

More information about the Slate mailing list