[PROPOSAL] MMD: multi sub syntax
Leopold Toetsch
multi subs into the assembler. Albeit we even have two sets of MMD
function registering opcodes (object.ops:mmd* , pmc.ops:mmdvt*) these
are not adequate to implement a general MMD scheme. The opcodes allow
just 2-dimensional MMD and second, the opcodes don't really help to
define multi subs, as the MMD information should be attached to the Sub
object itself and not be created from distance by some opcode, IMHO.
Syntax proposal:
.sub foo @MULTI
.invocant Integer a
.invocant Float b
.param pmc c
...
The @MULTI pragma goes along with the C<pcc_sub_proto>, it just adds
another flag bit.
The C<.invocant> can easily be parsed in the C<sub_params> rule, the
terminal C<.invocant> is already defined. The C<type> rule allows
currently to specify only known types, this check can be skipped so that
arbitrary class names can be specified.
Comments welcome,
leo
Leopold Toetsch
> Syntax proposal:
> .sub foo @MULTI
> .invocant Integer a
> .invocant Float b
> .param pmc c
> ...
Alternate syntax:
.sub foo multi(Integer, Float)
.param pmc a
.param pmc b
.param pmc c
I'm now more inclined towards the second one: @MULTI smells too much
like the pragmas @ANON or @LOAD and the second form is possibly simpler
to extend if needed. The syntax plays also more nicely with plain
methods:
.sub bar method
and eventually with
.sub baz multi(String, int), method
Comments?
leo
Jonathan Worthington
> Leopold Toetsch <l...@toetsch.at> wrote:
>
>> Syntax proposal:
>
>> .sub foo @MULTI
>> .invocant Integer a
>> .invocant Float b
>> .param pmc c
>> ...
>
> Alternate syntax:
>
> .sub foo multi(Integer, Float)
> .param pmc a
> .param pmc b
> .param pmc c
>
first two parameter's types twice (pmc and Integer, pmc and Float), which
I'm not sure is a good idea. Of course, there is...
.sub foo multi(Integer a, Float b)
.param pmc c
Though I don't know how I feel about that either (or rather, I'm not sure
how other folks will).
Thanks,
Jonathan
Chromatic
I like the first one in that it has the names and the types of the
parameters in one place. Does it need the @MULTI attribute if there are
some parameters declared with .invocant?
-- c
Bob Rogers
Date: Mon, 14 Mar 2005 14:02:30 +0100
Leopold Toetsch <l...@toetsch.at> wrote:
> Syntax proposal:
> .sub foo @MULTI
> .invocant Integer a
> .invocant Float b
> .param pmc c
> ...
Alternate syntax:
.sub foo multi(Integer, Float)
.param pmc a
.param pmc b
.param pmc c
What if one wants the first and third arguments to be the invocants?
Then the first syntax gives
.sub foo @MULTI
.invocant Integer a
.param pmc b
.invocant String c
...
But it's not as obvious how to do that for the second one, unless you
use "pmc" as the explicit type name for "any":
.sub foo multi(Integer, pmc, String)
.param pmc a
.param pmc b
.param pmc c
In that case the first syntax strikes me as cleaner . . .
-- Bob Rogers
http://rgrjr.dyndns.org/
Chromatic
> What if one wants the first and third arguments to be the invocants?
> Then the first syntax gives
>
> .sub foo @MULTI
> .invocant Integer a
> .param pmc b
> .invocant String c
> ...
>
> But it's not as obvious how to do that for the second one, unless you
> use "pmc" as the explicit type name for "any":
>
> .sub foo multi(Integer, pmc, String)
> .param pmc a
> .param pmc b
> .param pmc c
It's not as bad as it seems. Because all three parameters use different
registers, the order of the parameters in the signature here doesn't
matter. (It may matter to the multi-method dispatcher, but it doesn't
matter to the call. I also think it shouldn't matter to the
dispatcher.)
I'm not sure of any case in practice where having a non-dispatchable
parameter between invocants makes sense with multi-methods, though. Do
you have an example in mind?
-- c
Leopold Toetsch
> What if one wants the first and third arguments to be the invocants?
> Then the first syntax gives
> .sub foo @MULTI
> .invocant Integer a
> .param pmc b
> .invocant String c
That should better be
> .sub foo @MULTI
> .invocant Integer a
> .invocant pmc b
> .invocant String c
Invocants are positional arguments, there isn't a case where the first
and the third are invocants in a Perl6 function signature. It of course
boils down to the same, namely that the second argument is a wildcard
(Perl6 Any) but it's for the dispatcher nethertheless a dispatch on
three invocants.
> But it's not as obvious how to do that for the second one, unless you
> use "pmc" as the explicit type name for "any":
> .sub foo multi(Integer, pmc, String)
> .param pmc a
> .param pmc b
> .param pmc c
> In that case the first syntax strikes me as cleaner . . .
I'm not sure. But there is still another thingy. A12 allows multiple
colons to separate invocant "classes". If there is a tie, the secondary
invocants are used as tie breakers, which could be written as:
.sub foo multi(Integer, pmc: String)
.param pmc a
.param pmc b
.param pmc c
- try to dispatch on the first two types in the first place
- if there is a tie, consider the type of the 3rd argument
leo
Bob Rogers
Date: Tue, 15 Mar 2005 08:52:38 +0100
Bob Rogers <rogers...@rgrjr.dyndns.org> wrote:
> What if one wants the first and third arguments to be the invocants?
> Then the first syntax gives
> .sub foo @MULTI
> .invocant Integer a
> .param pmc b
> .invocant String c
That should better be
> .sub foo @MULTI
> .invocant Integer a
> .invocant pmc b
> .invocant String c
Invocants are positional arguments, there isn't a case where the first
and the third are invocants in a Perl6 function signature. It of course
boils down to the same, namely that the second argument is a wildcard
(Perl6 Any) but it's for the dispatcher nethertheless a dispatch on
three invocants.
Thanks for clearing that up. (FWIW, your answer accords well with my
personal biases, too. ;-)
> . . .
> In that case the first syntax strikes me as cleaner . . .
I'm not sure. But there is still another thingy. A12 allows multiple
colons to separate invocant "classes". If there is a tie, the secondary
invocants are used as tie breakers, which could be written as:
.sub foo multi(Integer, pmc: String)
.param pmc a
.param pmc b
.param pmc c
- try to dispatch on the first two types in the first place
- if there is a tie, consider the type of the 3rd argument
leo
I've only read half of A12 by now, and am still digesting what I've read
(and that may take a while), but the section headed "multi sub *
(tradition multimethods)" seems to say that the dispatcher never
considers anything after the last colon. So perhaps you meant:
.sub foo multi(Integer, pmc: String:)
.param pmc a
.param pmc b
.param pmc c
Or is that wrong?
The next question is, what happens if you define a method with the
"long name":
.sub bar multi(Integer, Float: Float)
and I define one with
.sub bar multi(Integer: String, Integer)
That would mean that the "long names" have different "name length" in
this case. It seems to me that can't work, but if A12 rules it out, I
couldn't find it.
If this is supposed to work, then how should MMD handle disagreement
about invocant groups? And if the answer is simply to ignore it, and
treat each method independently, doesn't this screw up the distance
metric? The distance to your method will be computed on the first two
values, whereas the distance to mine will be computed on only the first,
so the two distances will be incommensurable, true?
TIA,
Leopold Toetsch
> From: Leopold Toetsch <l...@toetsch.at>
> .sub foo multi(Integer, pmc: String)
> .param pmc a
> .param pmc b
> .param pmc c
> - try to dispatch on the first two types in the first place
> - if there is a tie, consider the type of the 3rd argument
> leo
> I've only read half of A12 by now, and am still digesting what I've read
> (and that may take a while), but the section headed "multi sub *
> (tradition multimethods)" seems to say that the dispatcher never
> considers anything after the last colon. So perhaps you meant:
> .sub foo multi(Integer, pmc: String:)
It depends: if the C<multi> just contains the MMD signature my version
is fine.
> The next question is, what happens if you define a method with the
> "long name":
> .sub bar multi(Integer, Float: Float)
> and I define one with
> .sub bar multi(Integer: String, Integer)
> That would mean that the "long names" have different "name length" in
> this case. It seems to me that can't work, but if A12 rules it out, I
> couldn't find it.
If the multi sub is called with an Integer argument (or a class derived
from Integer) all "bar" methods of these classes are included in the
candidate list. The different "long name length" doesn't matter for that.
> If this is supposed to work, then how should MMD handle disagreement
> about invocant groups? And if the answer is simply to ignore it, and
> treat each method independently, doesn't this screw up the distance
> metric? The distance to your method will be computed on the first two
> values, whereas the distance to mine will be computed on only the first,
> so the two distances will be incommensurable, true?
Seems so yes. Except, if shorter (not so specific) long names get a
penalty. This seems to need clarification from p6l.
> TIA,
> -- Bob Rogers
leo
Leopold Toetsch
>> Syntax proposal:
>> .sub foo @MULTI
>> .invocant Integer a
>> .invocant Float b
>> .param pmc c
>> ...
> Alternate syntax:
> .sub foo multi(Integer, Float)
> .param pmc a
> .param pmc b
> .param pmc c
And another one:
.multi sub foo
.sub foo__Int_Num_Str Integer,Float:String
.sub foo__Num_Int_Any Float,Integer,pmc
.endmulti
.sub foo__Int_Num_Str
...
.sub foo__Num_Int_Any
...
The C<.multi> defines a group of multi subs with it's short name. The
members are plain subroutines with their long names. Name mangling is
done by Perl6.
leo
Dan Sugalski
>Leopold Toetsch <l...@toetsch.at> wrote:
>> Leopold Toetsch <l...@toetsch.at> wrote:
>
>>> Syntax proposal:
>
>>> .sub foo @MULTI
>>> .invocant Integer a
>>> .invocant Float b
>>> .param pmc c
>>> ...
>
>> Alternate syntax:
>
>> .sub foo multi(Integer, Float)
>> .param pmc a
>> .param pmc b
>> .param pmc c
>
>And another one:
>
> .multi sub foo
> .sub foo__Int_Num_Str Integer,Float:String
> .sub foo__Num_Int_Any Float,Integer,pmc
> .endmulti
Since the sub PMC's going to have to be installed in the MMD tables
at load time with some amount of force (since there's going to have
to be type lookups, amongst other things, that need to be done) I
think we might as well go for something easy to parse. If I had my
choice, I think I'd go with:
.sub foo @MULTI(Integer, -, Float)
where the @MULTI() carries the signature, with a dash denoting
positions whose types are ignored for purposes of MMD lookup.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk