I've been looking at various Perl6 operators in terms of what their
implementation would look at the Parrot level. Junctions struck me as
possibly highly problematic. The issue is, how would one go about
compiling them at the point when they get passed to a function call as 1
of the parameters.
For instance, in pugs, this works:
pugs> my $a = 1|2
(1 | 2)
pugs> sin $a
(0.8414709848078965 | 0.9092974268256817)
pugs> sub foo() { return 1|2; }
pugs> foo()
(1 | 2)
pugs> sin foo
(0.8414709848078965 | 0.9092974268256817)
I came up with two ways:
1) Use Junction PMC that overloads various conversion entries in its
vtable. Operators will have to use continuations to loop over junction
contents.
-- This seems a non-starter, as vtable entries can't spawn a
continuation that can reenter them. (right?)
2) Expand explicitly.
-- Problem is, you need to insert checks for each parameter before each
function call, if a junction can be assigned to a variable like above.
This means that perl6 calling convention would have to explicitly
typecheck parameters everywhere. This strikes me as much less efficient
then, say, checking for ties everywhere. And ties have to be explicitly
declared.
Would it make sense to require that Junctional variables *MUST* be
declared as such, and same with function that return junctions? Strict
reading of S9 seems to imply that this already is the case, but possibly
a clarification with some examples might be in order.
So the example above would read:
my Junction $a = 1|2
sub foo(--> Junction) { return 1|2; }
And hope this topic hasn't already been rehashed. :)
Miro
