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