Yay...verbose commit messages = I can haz useful input. :-)
Patrick R. Michaud wrote:
On Fri, Sep 12, 2008 at 05:03:20PM -0700, [EMAIL PROTECTED] wrote:
[...]
(2) Test.pm gets Object rather than Any on its multis;
this may or may not be the Right Thing.
perl6-language may end up disagreeing with me on this, but I would
much prefer things (from a implementation bootstrapping perspective)
if Test.pm didn't rely on type checking and Junctions in order to
work properly. So, until we hear otherwise, it might be better to
not require Object on parameters here.
Yes - I think you're right. It did it so we could keep on passing the
junction tests for the time being. We can either:
* Rely on auto-threading, once the dispatcher handles that, to thread
calls into Test.pm for us - but that may lead to various oddness ("I
though I was calling ok once but called it twice?!"). But junction
auto-threading isn't quite with us yet (need to tackle the dispatcher...)
* Modify the junctions tests to make sure they never will pass a
junction into Test.pm. If Test.pm isn't to have to handle junctions,
then I suspect this is our best option.
Of course, we can also remove Object now and stop running the junctions
tests too. But I thought it better to put something in place, even if
temporary, to keep us passing them for the time being while the Right
Answer was worked out. (The only reason they were passing before is
because we had the dispatch/type-checking semantics wrong. We still do
have it wrong on non-multis, which will have to change soon too, to get
auto-threading to work.)
(3) Because Parrot doesn't yet give us a way to type-map MultiSub,
and because we're not using .HLL yet anyway, we need to do a
workaround in a block's loadinit.
Instead of having a special '!TOPERL6MULTISUB' function, could
this be done instead with 'morph'?
Maybe with some special logic in the MultiSub PMC, but I don't think as
the way things are at the moment we could do that.
If that doesn't work, perhaps we could get it to work using the 'add_sub'
method on NameSpace PMCs (and perhaps this should be part of a Perl6NameSpace
class)?
I was expecting that we'd HLL map MultiSub and just get the correct type
in the first place, rather than having to fix it up later (since fixing
it up later is runtime cost, which feels like something we shouldn't
need for this). Or are there cases HLL map isn't going to handle for us?
Thanks,
Jonathan
