S6 multimethod invocants
Paul
multi handle_event ($window, $event: $mode) {...} # two invocants
Does that mean I can assume $event is a valid object of some sort?
.stuff()
is still going to default to $window, right?
Or is that saying that if there is no $window.stuff() it'll look for
$event.stuff() ? This is all very confusing. :)
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Luke Palmer
>
> multi handle_event ($window, $event: $mode) {...} # two invocants
>
> Does that mean I can assume $event is a valid object of some sort?
Yep.
multi handle_event ($window, Undef $event: $mode) {...}
Then you would get a valid undef object. :)
> .stuff()
>
> is still going to default to $window, right?
Yes. $_ binds to the first invocant.
> Or is that saying that if there is no $window.stuff() it'll look for
> $event.stuff() ?
No. If there's no $window.stuff, you'll get an error.
Luke
Paul
--- Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
> > Ok, this is strange to me.
> > multi handle_event ($window, $event: $mode) {...} # two invocants
> > Does that mean I can assume $event is a valid object of some sort?
>
> Yep.
> multi handle_event ($window, Undef $event: $mode) {...}
> Then you would get a valid undef object. :)
okay....and why would I want that?
> > .stuff()
> > is still going to default to $window, right?
>
> Yes. $_ binds to the first invocant.
Okay, that makes expected sense....
> > Or is that saying that if there is no $window.stuff() it'll look
> > for $event.stuff() ?
>
> No. If there's no $window.stuff, you'll get an error.
Okay, but I thought the main point of multimethods was that it could be
redefined and would be dynamically dispatched to the correct version
based on the invocant and/or arguments, i.e., the signature.
What, exactly, is the value of calling multiple arguments to one method
call "invocants"? I'm *really* missing something, here.....
Austin Hastings
The multidispatch is done on the invocants, only.
multi infix:= (Int $i: String $s) {...}
multi infix:= (Float $f: String $s) {...}
If you say
my Int $j;
$j = "foobar";
The dispatch will chase down the (Int/String) version.
If you say:
$j = new Dog("Spot");
The dispatcher will NOT look for an (Int/Dog) signature. Instead, it
will either blow up, or invoke Dog("Spot").toString -- I'm not sure
which.
=Austin
Paul
--- Austin Hastings <austin_...@yahoo.com> wrote:
> --- Paul <ydb...@yahoo.com> wrote:
> > Okay, but I thought the main point of multimethods was that it
> > could be redefined and would be dynamically dispatched to the
> > correct version based on the invocant and/or arguments, i.e.,
> > the signature.
>
>
> multi infix:= (Int $i: String $s) {...}
> multi infix:= (Float $f: String $s) {...}
>
> If you say
>
> my Int $j;
>
> $j = "foobar";
>
> The dispatch will chase down the (Int/String) version.
>
> If you say:
>
> $j = new Dog("Spot");
>
> The dispatcher will NOT look for an (Int/Dog) signature. Instead, it
> will either blow up, or invoke Dog("Spot").toString -- I'm not sure
> which.
whoa....
multi foo ($me: Int $x) {...}
multi foo ($me: Dog $x) {...}
doesn't work to delegate by sig? I must've *REALLY* misread something
somewhere....
Luke Palmer
Ouch. Please don't do that.
> The dispatch will chase down the (Int/String) version.
>
> If you say:
>
> $j = new Dog("Spot");
Note that this is not valid syntax any longer. Well, it is, but not
how you think. It means call the Dog function with an argument
"Spot", and try to give that as an argument to the new function. If
there is no new function, call the new method on that argument
(because the colon is optional when the invocant is the only
parameter).
To get what you want, you need to say either of:
$j = Dog.new("Spot");
$j = new Dog: "Spot";
> The dispatcher will NOT look for an (Int/Dog) signature. Instead, it
> will either blow up, or invoke Dog("Spot").toString -- I'm not sure
> which.
That's automatic conversion policy, and nobody knows which yet.
That's A12, too, I think.
After A11, I'll be dying in anticipation. Er, moreso than I am
already....
Luke
Austin Hastings
From A6:
[quote]
Positional parameters
The three positional parameter types are the invocant, the required
parameters, and the optional positional parameters.
...
The invocant
The first argument to any method (or submethod) is its invocant, that
is, the object or class upon which the method is acting. The invocant
parameter, if present, is always declared with a colon following it.
...
Multimethods can have multiple invocants. A colon terminates the list
of invocants, so if there is no colon, all parameters are considered
invocants. Only invocants participate in multimethod dispatch. Only the
first invocant is bound to $_.
[/quote]
=Austin
Paul
> of invocants, so if there is no colon, all parameters are considered
> invocants. Only invocants participate in multimethod dispatch. Only
> the first invocant is bound to $_.
Which pretty much explains all of it, I think.
multi foo ($me, Int $i: *@x) {...} # version 1
multi foo ($me, String @s: *%x) {...} # version 2
multi foo ($me, $a, @b: *@x) {...} # version 3
These would dispatch based on their required args, since all the
required args happen to be invocants.
$o->foo(1); # calls version 1
$o->foo(qw/ this calls version 2 /);
$o->foo($x,@y); # calls version 3
right?
Austin Hastings
--- Paul <ydb...@yahoo.com> wrote:
> > Multimethods can have multiple invocants. A colon terminates the
> list
> > of invocants, so if there is no colon, all parameters are
> considered
> > invocants. Only invocants participate in multimethod dispatch. Only
> > the first invocant is bound to $_.
>
> Which pretty much explains all of it, I think.
>
> multi foo ($me, Int $i: *@x) {...} # version 1
> multi foo ($me, String @s: *%x) {...} # version 2
> multi foo ($me, $a, @b: *@x) {...} # version 3
>
> These would dispatch based on their required args, since all the
> required args happen to be invocants.
>
> $o->foo(1); # calls version 1
> $o->foo(qw/ this calls version 2 /);
> $o->foo($x,@y); # calls version 3
>
> right?
I think you've got it.
=Austin
Larry Wall
: > Multimethods can have multiple invocants. A colon terminates the list
: > of invocants, so if there is no colon, all parameters are considered
: > invocants. Only invocants participate in multimethod dispatch. Only
: > the first invocant is bound to $_.
:
: Which pretty much explains all of it, I think.
:
: multi foo ($me, Int $i: *@x) {...} # version 1
: multi foo ($me, String @s: *%x) {...} # version 2
: multi foo ($me, $a, @b: *@x) {...} # version 3
:
: These would dispatch based on their required args, since all the
: required args happen to be invocants.
:
: $o->foo(1); # calls version 1
: $o->foo(qw/ this calls version 2 /);
: $o->foo($x,@y); # calls version 3
:
: right?
Er, not quite. First, you want . rather than ->. Next, you don't
want . at all, unless you want to try single dispatch first and then
fall back on multimethod dispatch. You typically call a multimethod
as if it were a sub:
foo($o, 1); # calls version 1
foo($o, qw/ this calls version 2 /);
foo($o, $x,@y); # calls version 3
Also, the string type is Str, not String. Whether #2 works may
depend on whether the list returned by qw// is marked as type Str.
If not, it might be ambiguous. I don't know to what extent multimethod
dispatch should peek inside random scalars and try to guess whether
they're integers or strings.
Larry
Paul
> :
> : multi foo ($me, Int $i: *@x) {...} # version 1
> : multi foo ($me, String @s: *%x) {...} # version 2
> : multi foo ($me, $a, @b: *@x) {...} # version 3
> :
> : These would dispatch based on their required args, since all the
> : required args happen to be invocants.
> :
> : $o->foo(1); # calls version 1
> : $o->foo(qw/ this calls version 2 /);
> : $o->foo($x,@y); # calls version 3
> :
> : right?
>
> Er, not quite. First, you want . rather than ->.
ARGH! LOL! Habit kicking in again. :)
> Next, you don't want . at all, unless you want to try single
> dispatch first and then fall back on multimethod dispatch. You
> typically call a multimethod as if it were a sub:
>
> foo($o, 1); # calls version 1
> foo($o, qw/ this calls version 2 /);
> foo($o, $x,@y); # calls version 3
Huh? Why? And could you elaborate "try single dispatch first and then
fall back on multimethod dispatch"? Suddenly I feel stupid again. :)
> Also, the string type is Str, not String.
Ok. Didn't check, but Good To Know.
> Whether #2 works may depend on whether the list returned by qw//
> is marked as type Str. If not, it might be ambiguous. I don't know
> to what extent multimethod dispatch should peek inside random scalars
> and try to guess whether they're integers or strings.
> Larry
Hmm... hadn't thought about that, either.
Probably Scalar rather that Str, yes?
Speaking of which, can we typecast?
my @a = String qw/ 1 2 3 / ;
Looks bogus to me, but the effect could come in handy. Maybe
my String @a = 1..3;
is better?
Michael Lazzaro
> Er, not quite. First, you want . rather than ->. Next, you don't
> want . at all, unless you want to try single dispatch first and then
> fall back on multimethod dispatch. You typically call a multimethod
> as if it were a sub:
>
> foo($o, 1); # calls version 1
> foo($o, qw/ this calls version 2 /);
> foo($o, $x,@y); # calls version 3
Doh! Now I'm confused. I assume that you can have multimethoding
methods, e.g:
method foo($self: Point $p) {...} # variant 1
method foo($self: int $x, int $y) {...} # variant 2
Such that
$obj.foo($my_point); # calls (1)
$obj.foo($my_x,$my_y); # calls (2)
are dispatched to the appropriate places, right? Or would that be:
method foo($self, Point $p :) {...}
method foo($self, int $x, int $y :) {...}
Or are method variants different from multimethod variants?
MikeL
Austin Hastings
As A6 currently stands, that won't work -- only multi's are capable of
having multiple invocants:
multi foo(Foo $self, Point $p) {...}
multi foo(Foo $self, int $x, int $y) {...} # No colon means invoke ALL
>
> Or are method variants different from multimethod variants?
Good question.
On the one hand, I could believe "the arity is different, so there's no
need to worry about type-based dispatch" -- it just works. On the other
hand, I could believe "we hadn't thought about multidispatch in those
terms".
I think we've all just assumed that "obvious" stuff would work, but I
haven't seen any documentation for that, except "P6 will still be Perl"
(and therefore will DWIM).
=Austin
Paul
--- Uri Guttman <u...@stemsystems.com> wrote:
> P> my String @a = 1..3;
>
> i think that should be:
>
> my @a of Str = 1..3;
Ok,
my Dog $spot is Pet;
means $spot is an object of type Pet, and the value to be put in it is
to be of type Dog, right? So
my Str @a;
Doesn't make a lot of sense anyway, does it? Objects must be scalars?
But
my @a of Str = 1..3;
means @a is an array that will be holding Str values.
So I *could* do C-ish "typecasting" by taking an anonymous set of
values and declaring them like this:
@a = (1..3) is Str; # yes? bogus? I dunno.
Can you set properties on sets like that? I know I could say
@a is Str = 1..3; # right?
But isn't that a different animal?
Uri Guttman
P> means @a is an array that will be holding Str values.
P> So I *could* do C-ish "typecasting" by taking an anonymous set of
P> values and declaring them like this:
P> @a = (1..3) is Str; # yes? bogus? I dunno.
i think that is bogus. the trait (the 'is' stuff) must follow the
declaration. traits affect variables and not values.
also if @a was declared/used before this, i think that would be a
compile time error to redeclare it. traits can only be used on a
declaration and not on any general assignment. i don't think there is c
style typecasting. you can assign to another type of var but its
implementation has to decide if it likes the data you are giving it. it
may allow it and internally do some 'casting'. and perl 'casting'
usually would involve real munging of data or putting it in a different
slot in the PMC or something. c's casting rarely changes the data
(except for float/int) - it usually just changes the type.
P> Can you set properties on sets like that? I know I could say
P> @a is Str = 1..3; # right?
you still need parens around that list (i think).
P> But isn't that a different animal?
maybe but one of the animals maybe mythical. :)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Uri Guttman
>> Next, you don't want . at all, unless you want to try single
>> dispatch first and then fall back on multimethod dispatch. You
>> typically call a multimethod as if it were a sub:
>>
>> foo($o, 1); # calls version 1
>> foo($o, qw/ this calls version 2 /);
>> foo($o, $x,@y); # calls version 3
P> Huh? Why? And could you elaborate "try single dispatch first and then
P> fall back on multimethod dispatch"? Suddenly I feel stupid again. :)
well, if there is a plain sub foo declared in scope (or whatever) it
will be called regardless of any multi foo declarations. if none is
found then a search for multi foo's will be done and multidispatch will
pick the 'best' one to call.
as for feeling stupid again, it is all part of the p6 game and we are
all players. :)
P> Probably Scalar rather that Str, yes?
P> Speaking of which, can we typecast?
P> my @a = String qw/ 1 2 3 / ;
P> Looks bogus to me, but the effect could come in handy. Maybe
P> my String @a = 1..3;
P> is better?
i think that should be:
my @a of Str = 1..3;
maybe that is just a synonym for your version. i am still (in)digesting
A6/S6. :)
@a is not a Str but its elements are.
Paul
> P> means @a is an array that will be holding Str values.
> P> So I *could* do C-ish "typecasting" by taking an anonymous set of
> P> values and declaring them like this:
>
> P> @a = (1..3) is Str; # yes? bogus? I dunno.
>
> i think that is bogus. the trait (the 'is' stuff) must follow the
> declaration. traits affect variables and not values.
Ah, very true.
@a = (1..3) but Str; # but for values
as in "return 0 but true;" stuff. Yes?
> also if @a was declared/used before this, i think that would be a
> compile time error to redeclare it. traits can only be used on a
> declaration and not on any general assignment.
That's not a declaration -- it's just an assignment.
The "but Str" is saying the 1..3 should be interpreted as string
values.
> i don't think there is c style typecasting. you can assign to another
> type of var but its implementation has to decide if it likes the data
> you are giving it. it may allow it and internally do some 'casting'.
> and perl 'casting' usually would involve real munging of data or
> putting it in a different slot in the PMC or something. c's casting
> rarely changes the data (except for float/int) - it usually just
> changes the type.
But on a standard scalar, aren't 1 and "1" seperate values, both stored
internally to the scalar and selected according to the context? And in
most cases, if the context calls for one that hasn't been populated,
doesn't it tend to do so on the fly from the value of the other?
That's how I kind of envisioned the P5 behavior. What's P6 do?
> P> Can you set properties on sets like that? I know I could say
> P> @a is Str = 1..3; # right?
>
> you still need parens around that list (i think).
Why?
@a = 1..3;
has always worked. Is that a new restriction in P6?
Seems unlikely....
> P> But isn't that a different animal?
>
> maybe but one of the animals maybe mythical. :)
lol....probably so. ;o]
Uri Guttman
P> --- Uri Guttman <u...@stemsystems.com> wrote:
>> >>>>> "P" == Paul <ydb...@yahoo.com> writes:
P> means @a is an array that will be holding Str values.
P> So I *could* do C-ish "typecasting" by taking an anonymous set of
P> values and declaring them like this:
>>
P> @a = (1..3) is Str; # yes? bogus? I dunno.
>>
>> i think that is bogus. the trait (the 'is' stuff) must follow the
>> declaration. traits affect variables and not values.
P> Ah, very true.
P> @a = (1..3) but Str; # but for values
P> as in "return 0 but true;" stuff. Yes?
that looks ok but i am not qualified to judge p6 code yet. :)
P> But on a standard scalar, aren't 1 and "1" seperate values, both stored
P> internally to the scalar and selected according to the context? And in
P> most cases, if the context calls for one that hasn't been populated,
P> doesn't it tend to do so on the fly from the value of the other?
P> That's how I kind of envisioned the P5 behavior. What's P6 do?
my take is that is still the same in p6. but it really is an
implementation issue whether both string and integer forms are cached. i
am fairly sure parrot is supporting this since it is a good
optimization.
P> Can you set properties on sets like that? I know I could say
P> @a is Str = 1..3; # right?
>>
>> you still need parens around that list (i think).
P> Why?
P> @a = 1..3;
P> has always worked. Is that a new restriction in P6?
P> Seems unlikely....
true. i just use parens for lists. it is needed in a few places such as
the left side of the x op to really get a list.
Brent Dax
# $j = new Dog("Spot");
#
# The dispatcher will NOT look for an (Int/Dog) signature. Instead, it
# will either blow up, or invoke Dog("Spot").toString -- I'm not sure
# which.
Depends on whether you've used strict 'types' at the site of the call.
Or at least it did last week.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
Brent Dax
# @a = (1..3) is Str; # yes? bogus? I dunno.
You're working way too hard.
@a = >~< (1..3); #Or is that <~>?
Note: do not take this to imply that I like the current hyperoperator
syntax--I don't.
Brent Dax
# Paul:
# # @a = (1..3) is Str; # yes? bogus? I dunno.
#
# You're working way too hard.
#
# @a = >~< (1..3); #Or is that <~>?
And Outlook was way too smart for its own good--those were supposed to
be doubled, but Outlook converted them and then something turned them
single. Meh.
Correct version:
@a = >>~<< (1..3); #Or is that <<~>>?
--Brent Dax <bren...@cpan.org>
Damian Conway
>> method foo($self, Point $p :) {...}
>> method foo($self, int $x, int $y :) {...}
>
>
> As A6 currently stands, that won't work -- only multi's are capable of
> having multiple invocants:
>
> multi foo(Foo $self, Point $p) {...}
> multi foo(Foo $self, int $x, int $y) {...} # No colon means invoke ALL
Correct.
You can have two or more multimethod variants of a given name, but only one
method of a given name (in a given namespace).
>>Or are method variants different from multimethod variants?
Yes. The former don't exist. ;-)
Just to clarify:
* Methods have exactly one invocant, and are dispatched solely on the
basis of the run-time type of that invocant.
* Multimethods can have one or more invocants, and are dispatched
solely on the basis of the run-time types of all their invocants.
* Both methods and multimethods can also have non-invocant parameters
(declared after the colon), but the corresponding arguments take no
part in the dispatch process.
Thus calls to the multimethod &foo:
multi foo(Window $w, Event $e : Mode $m) {...}
multi foo(Window $w, Str $e_name : Lode $l) {...}
multi foo(Str $w_name, Event $e : Wode $w) {...}
only consider their first two arguments when selecting which variant to invoke.
Damian
Damian Conway
> whoa....
>
> multi foo ($me: Int $x) {...}
> multi foo ($me: Dog $x) {...}
>
> doesn't work to delegate by sig? I must've *REALLY* misread something
> somewhere....
Yep. You missed the bit that says that multimethods only dispatch on their
invocants (i.e. the parameters declared before the colon). What you wrote
would probably induce a compile-time error:
Inconsistent declaration of multi foo($me:...)
What you wanted was:
multi foo ($me, Int $x:) {...}
multi foo ($me, Dog $x:) {...}
or just:
multi foo ($me, Int $x) {...}
multi foo ($me, Dog $x) {...}
(since the absence of a colon in a multi declaration implies all parameters
are invocants).
Damian
Paul
--- Brent Dax <bren...@cpan.org> wrote:
> Paul:
> # @a = (1..3) is Str; # yes? bogus? I dunno.
>
> You're working way too hard.
>
> @a = >~< (1..3); #Or is that <~>?
>
> Note: do not take this to imply that I like the current hyperoperator
> syntax--I don't.
lol -- which is why there are times I'd *SO* much rather work a little
more. :)
Stéphane Payrard
If I get things right: what would be implemented in C++ with overloaded
methods will be implemented in Perl6 with multimethods.
--
stef
>
> Damian
>
>
>
>
Larry Wall
:
: >whoa....
: >
: > multi foo ($me: Int $x) {...}
: > multi foo ($me: Dog $x) {...}
: >
: >doesn't work to delegate by sig? I must've *REALLY* misread something
: >somewhere....
:
: Yep. You missed the bit that says that multimethods only dispatch on their
: invocants (i.e. the parameters declared before the colon). What you wrote
: would probably induce a compile-time error:
:
: Inconsistent declaration of multi foo($me:...)
Undifferentiated declarations of multi foo($me:...)
On the other hand, it might just fall into the category of:
Redeclaration of &foo($:) at line 123...
Larry