Multiple colons

[Luke Palmer]

Hey grep { !/Luke/ } @Larry,

<luqui> multi foo(Foo, Bar: Baz); # manhattan on Foo and Bar
<luqui> multi foo(Foo: Bar: Baz); # leftmost on Foo and Bar
<autrijus> wtf?
<autrijus> 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. Maybe I'm just not looking
hard enough...

Luke

[Autrijus Tang]

On Tue, May 17, 2005 at 07:00:23AM -0700, Larry Wall wrote:
> On Tue, May 17, 2005 at 01:50:48PM +0000, 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/

[Luke Palmer]

On 5/17/05, Larry Wall <la...@wall.org> 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

[Larry Wall]

On Tue, May 17, 2005 at 01:50:48PM +0000, Luke Palmer wrote:

: Hey grep { !/Luke/ } @Larry,

:
: <luqui> multi foo(Foo, Bar: Baz); # manhattan on Foo and Bar
: <luqui> multi foo(Foo: Bar: Baz); # leftmost on Foo and Bar
: <autrijus> wtf?
: <autrijus> 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

[Larry Wall]

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 +0000, 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

[Autrijus Tang]

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/

[Larry Wall]

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

[Autrijus Tang]

On Tue, May 17, 2005 at 02:45:58PM +0000, 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/