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