On Sun Nov 23 10:33:24 2008, moritz wrote:
> On Sat Oct 18 17:15:30 2008, bacek wrote:
> > Hello.
> >
> > 00:05 bacek
> > rakudo: my $a; $a = $a + 1i; say $a
> >
> > 00:05 polyglotbot
> > OUTPUT[Multiple Dispatch: No suitable candidate found for 'add', with
> > signature 'PPP->P'current instr.: 'infix:+' pc 1941
> > (src/gen_builtins.pir:1368)called from Sub '_block11' pc 60
> > (EVAL_12:25)called from Sub 'parrot;PCT;HLLCompiler;eval' pc 864
> > (src/PCT/HLLCompiler.pir:498)called from Sub
>
> Added test to the test suite in (pugs) r23061,
> t/spec/S03-operators/autovivification.t
>
Fixed in r33214 and test unfudged.
Note on the fix and what I'm guessing general direction may be on such
things. I did it by implementing .Complex (which I believe should exist
as a method on Any), which is what coerces something to Complex. Types
can override this if they want to coerce in their own special way.
I suspect when we write things such as the infix:<+> in a Perl 6 prelude
we'll end up writing something like:
multi method infix:<+>(Complex $a, $b as Complex) { ... }
Which could coerce that second parameter into being a Complex (note that
the Complex method actually returns a Complex, and doesn't modify the
original value).
I believe the Any method would also be exported...
multi method Complex() is export { ... }
So we'll get a sub form too...
Complex(...)
But trying to introduce a sub form right now causes clashes with the
Complex proto-object in the namespace. Ouch. :-( Anyway, that's a wider
issue and not specific to this ticket, so treating as resolved.
Jonathan
