Re: Multiple colons
Autrijus Tang wrote:
I think the former is simpler ("always use coercion"), but the latter
makes it possible to define various other things that, although not
isomorphic with builtin numbers, can still use arithmetic operators.
I haven't understood what Larry meant with hard constraint but I would
opt for ([3]). In general the builtin operators should be grouped into
roles which are in turn composed into classes like Num which implement
them.
--
TSa (Thomas Sandlaß)
Re: Multiple colons
On Wed, May 18, 2005 at 04:02:16AM +0800, Autrijus Tang wrote:
: Hmm. How does this play with Larry's suggestion:
:
: I suppose one could even install a colon on the end of the return
: type to request that explicitly.
:
: Does it mean that:
:
: multi sub foo(Foo: Bar: Baz:) returns Boo {...}
: multi sub foo(Foo: Bar: Baz:) returns Foo {...}
:
: would MMD on the return type, but still ignore the "Baz" for MMD?
No, I meant:
multi sub foo(Foo: Bar: Baz) returns Boo: {...}
multi sub foo(Foo: Bar: Baz) returns Foo: {...}
But that's a bit strange, and in any event it's problematical to depend
on a context that might not be known till after we call foo() anyway,
unless even the dispatch to foo() is done lazily.
Larry
Re: Multiple colons
On Tue, May 17, 2005 at 02:45:58PM +, Luke Palmer wrote:
> Just for the folks not following along on IRC, I don't think I implied
> that. But Autrijus apparently inferred it :-).
My apologies. It's a misparse on my part.
> Anyway, there is no MMD whatsoever on the final level, so that:
>
> multi sub foo(Foo: Bar: Baz) {...}
> multi sub foo(Foo: Bar: Quux) {...} # illegal redefinition
Hmm. How does this play with Larry's suggestion:
I suppose one could even install a colon on the end of the return
type to request that explicitly.
Does it mean that:
multi sub foo(Foo: Bar: Baz:) returns Boo {...}
multi sub foo(Foo: Bar: Baz:) returns Foo {...}
would MMD on the return type, but still ignore the "Baz" for MMD?
Thanks,
/Autrijus/
pgpSWytLLuVDk.pgp
Description: PGP signature
Re: Multiple colons
On Tue, May 17, 2005 at 07:26:54AM -0700, Larry Wall wrote:
> It does seem that the signature that provides more information should
> be "rewarded" for that somehow. Maybe it's most useful if non-invocant
> args (or non-invocant-YET args, in this case) are just considered to
> be at "Any" distance when matched against "real" invocants. But we
> also have to consider that any violated hard constraint anywhere in
> the signature can disqualify the entrant entirely.
So, if neither Num.does(Str) nor Str.does(Num), is passing a "string" into
multi sub foo (Num $x) { ... }
considered a violation on the hard constraint?
If yes, I'd like to know if something like this should be the case ([1]):
Num is a class, and
NumRole supplying a minimal definition of prefix:<+>
or it's like this instead ([3]):
Num is a role, and
has a minimal interface of:
infix:<+> infix:<*> abs sign
and one of: prefix:<-> infix:<->
etc.
I think the former is simpler ("always use coercion"), but the latter
makes it possible to define various other things that, although not
isomorphic with builtin numbers, can still use arithmetic operators.
Thanks,
/Autrijus/
pgpvJ0CD0eTFk.pgp
Description: PGP signature
Re: Multiple colons
Autrijus Tang wrote:
So does it mean that a "3-story" multisub with two colons will
always win against one with one colon?
multi sub foo (Any $x: Str $y: Str $z, Str $w) { 1 }
multi sub foo (Str $x, Str $y: Str $z, Str $w) { 2 }
say foo("x", "y", "z", "w"); # 1
Is the final level ($z and $w) participating in the MMD at all
as tiebreakers? Luke mentioned that in all levels but the final
one, Manhattan distance (sum of inheritance deltas of each invs
to the expected types) is used, but on the final level, leftmost
tiebreaking is used. Is that the case? If yes, why? :)
I'm also very keen on hearing the rationale behind these decisions.
Do I get it right that Luke is advocating something else
in @Larry? If yes, what?
I think the only difference apart from scoping issues between
a multi method and a multi sub is that the former has the first
parameter to be most specific on the class it is defined in.
Question: is this parameter always implicitly added or is the
double-colon syntax needed to give an explicit invocant identifier?
And how does that work together with the ./method syntax?
My concern is that all these tie breakers, special casing syntax
etc. are weakening the type system. Or putting it differently:
How is 'type error' defined? Note that I'm *not* asking at what
time it is detected---but it should be before the call or immediatly
after when the return type doesn't match the callers wants.
--
$TSa == all( none( @Larry ), one( @p6l ))
Re: Multiple colons
On 5/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Tue, May 17, 2005 at 10:10:22PM +0800, Autrijus Tang wrote:
> : Is the final level ($z and $w) participating in the MMD at all
> : as tiebreakers? Luke mentioned that in all levels but the final
> : one, Manhattan distance (sum of inheritance deltas of each invs
> : to the expected types) is used, but on the final level, leftmost
> : tiebreaking is used. Is that the case? If yes, why? :)
>
> I don't recall ever saying anything like that, so that part of it
> is presumably speculative on Luke's part. I can't say I like it.
Just for the folks not following along on IRC, I don't think I implied
that. But Autrijus apparently inferred it :-). Anyway, there is no
MMD whatsoever on the final level, so that:
multi sub foo(Foo: Bar: Baz) {...}
multi sub foo(Foo: Bar: Quux) {...} # illegal redefinition
Luke
Re: Multiple colons
On Tue, May 17, 2005 at 10:10:22PM +0800, Autrijus Tang wrote:
: On Tue, May 17, 2005 at 07:00:23AM -0700, Larry Wall wrote:
: > On Tue, May 17, 2005 at 01:50:48PM +, Luke Palmer wrote:
: > : Is that still the case? I don't recall us getting rid of it, but it
: > : doesn't seem to be documented in the AES.
: >
: > We didn't get rid of it.
:
: So does it mean that a "3-story" multisub with two colons will
: always win against one with one colon?
:
: multi sub foo (Any $x: Str $y: Str $z, Str $w) { 1 }
: multi sub foo (Str $x, Str $y: Str $z, Str $w) { 2 }
:
: say foo("x", "y", "z", "w"); # 1
It does seem that the signature that provides more information should
be "rewarded" for that somehow. Maybe it's most useful if non-invocant
args (or non-invocant-YET args, in this case) are just considered to
be at "Any" distance when matched against "real" invocants. But we
also have to consider that any violated hard constraint anywhere in
the signature can disqualify the entrant entirely.
: Is the final level ($z and $w) participating in the MMD at all
: as tiebreakers? Luke mentioned that in all levels but the final
: one, Manhattan distance (sum of inheritance deltas of each invs
: to the expected types) is used, but on the final level, leftmost
: tiebreaking is used. Is that the case? If yes, why? :)
I don't recall ever saying anything like that, so that part of it
is presumably speculative on Luke's part. I can't say I like it.
Larry
Re: Multiple colons
On Tue, May 17, 2005 at 07:00:23AM -0700, Larry Wall wrote:
> On Tue, May 17, 2005 at 01:50:48PM +, Luke Palmer wrote:
> : Is that still the case? I don't recall us getting rid of it, but it
> : doesn't seem to be documented in the AES.
>
> We didn't get rid of it.
So does it mean that a "3-story" multisub with two colons will
always win against one with one colon?
multi sub foo (Any $x: Str $y: Str $z, Str $w) { 1 }
multi sub foo (Str $x, Str $y: Str $z, Str $w) { 2 }
say foo("x", "y", "z", "w"); # 1
Is the final level ($z and $w) participating in the MMD at all
as tiebreakers? Luke mentioned that in all levels but the final
one, Manhattan distance (sum of inheritance deltas of each invs
to the expected types) is used, but on the final level, leftmost
tiebreaking is used. Is that the case? If yes, why? :)
Thanks,
/Autrijus/
pgpOwtC66i1df.pgp
Description: PGP signature
Re: Multiple colons
On Tue, May 17, 2005 at 01:50:48PM +, Luke Palmer wrote:
: Hey grep { !/Luke/ } @Larry,
:
: multi foo(Foo, Bar: Baz); # manhattan on Foo and Bar
: multi foo(Foo: Bar: Baz); # leftmost on Foo and Bar
: wtf?
: multiple colons?
:
: Is that still the case? I don't recall us getting rid of it, but it
: doesn't seem to be documented in the AES.
We didn't get rid of it.
: Maybe I'm just not looking hard enough...
Maybe we didn't document it hard enough...
But we have at times mentioned various "tiebreaking" situations.
"multi methods" (as opposed to "multi subs") are one instance, where
single dispatch to the class is followed by multiple dispatch within
the class, so it's equivalent to an extra colon. We've also talked
about the possibility of using return type for final tiebreaking.
I suppose one could even install a colon on the end of the return
type to request that explicitly.
Larry
