On 7/8/05, "TSa (Thomas Sandlaß)" <[EMAIL PROTECTED]> wrote:
> > * Constrained types in MMD position, as well as value-based MMDs, are _not_
> > resolved in the type-distance phase, but compile into a huge given/when
> > loop that accepts the first alternative. So this:
> >
> > multi sub foo (3) { ... }
> > multi sub foo (2..10) { ... }
> >
> > really means:
> >
> > multi sub foo ($x where { $_ ~~ 3 }) { ... }
> > multi sub foo ($x where { $_ ~~ 2..10 }) { ... }
> >
> > which compiles two different long names:
> >
> > # use introspection to get the constraints
> > &foo<ANONTYPE_1>
> > &foo<ANONTYPE_2>
> >
> > which really means this, which occurs after the type-based MMD tiebreaking
> > phase:
> >
> > given $x {
> > when 3 { &foo<ANONTYPE_1>.goto }
> > when 2..10 { &foo<ANONTYPE_2>.goto }
> > }
> > in the type-based phase, any duplicates in MMD is rejected as ambiguous;
> > but
> > in the value-based phase, the first conforming one wins.
>
> I hope that is a temporary "solution". Usually one would expect 3 beeing a
> more specific type then 2..10 irrespective of definition sequence.
Not unless you want to write the Halting engine that determines that 3
is in fact more specific that 2..10. It's based on definition order,
so that if you have dependencies in you condition (which you
oughtn't), you'd better define the multis together to get well-defined
semantics.
> > The upshot is that these are now errors:
> >
> > sub foo ($x) is rw { $x }
> > my $a;
> > foo($a) = 4; # runtime error - assign to constant
>
> I assumed lvalue subs would implicitly return void and an
> assignment goes to the function slot of the args used in the assignment
> and subsequent calls with these args return exactly this value.
> In that respect arrays and hashes are the prime examples of lvalue
> subs. Other uses are interpolated data, Delauny Triangulation etc.
Well, in the absence of optimization, what's usually going on is that
the lvalue sub is returning a tied proxy object, which you then call
STORE on.
Luke
