HaloO,
Larry Wall wrote:
: Yes, and dispatch as a runtime keyed access into a code multitude.
: The covariant part of the method's sig! The code equivalent to keyed
: data access into hashes.
Um, yeah. Won't play in Peoria, though.
Where or what is Peoria?
What I mean with the covariant part of a method sig stems from
the paper "G. Castagna. Covariance and contravariance: conflict
without a cause" available from
ftp://ftp.di.ens.fr/pub/users/castagna/covariance.ps.gz
: The left --> is just the virtualizer call. I tend to call
: that slot accessor. The return value of a dispatch is the
: not yet invoked but curried on the invocant(s) method. This
: two stage propcess is in my eyes nicely indicated by the
: two -->. But we could also but a : in the dispatch arrows
: like -:-> or :-> or -:> which all look somewhat ugly.
I kind of like : for that, actually. :-)
I have no objections. Actually I associate it with
the label syntax. But I hope we have the same understanding
what
multi method abc (A $a: B $b: C $c: X $x, Y $y) {...} #1
means in comparison to
multi method abc (A $a, B $b, C $c: X $x, Y $y) {...} #2
where I think that #1 is a mono method on A that yields a
mono method on B which in turn yields a mono method on C.
That is *three* successive dispatches which could branch out
into different targets in each step. E.g. with D a subtype of B
multi method abc (A $a: D $b: C $c: X $x, Y $y) {...} #3
The #2 target OTOH is a *single* target on the 3-tupel type :(A,B,C).
We could call the #1 and #3 dispatches tree-dispatch and #2
lattice-dispatch. Question is how do they relate to each other?
I would opt for :(A,B,C) beeing more specific than :(A). In other
words the cascaded dispatch competes in each step with n-tupel types.
E.g.
multi method abc (A $a: D $b, C $c: X $x, Y $y) {...} #4
outperforms :(B) from #1 and :(D) from #3 with its :(D,C) (sub)signature.
Note that
multi method abc (A $a: B $b, C $c: X $x, Y $y) {...} #5
would be ambigous in a pure regime because :(B,C) is not a strictly
more specific type than :(D).
After the successful selection of the target out of the targets #1
to #5 the contravariant part of the sig :(X,Y) is checked and then
the invocation procedes with binding the args to the params.
: method doit (...) on (invocant sig) { ... }
I don't see how that relates.
Take the example #2 from above which could be written
multi method abc (X $x, Y $y) on (A $a, B $b, C $c) {...}
and the cascading version as
multi method abc (X $x, Y $y) on (A $a) on (B $b) on (C $c) {...}
or with the invocants at the front
multi method on (A $a, B $b, C $c) abc (X $x, Y $y) {...}
But I'm not a native who could decide if 'method on' is the right
choice of preposition. Perhaps it should be 'method in'? But that
would further the conception of methods beeing inside of classes
which they are only in the special case of a dispatch implementation
through vtbls carried around by the objects. My old problem of 'is
the object or the method in charge'.
The metaphor that illustrates my point is that $ball.throw() looks
funny in my mind if you think of the $ball throwing itself. Compare
with $Larry.talk() where the talking style is inherent in $Larry.
: Well, we could take the ¢ sigil to form invocant twigils ¢$, ¢@, ¢%, ¢&
: which look a bit nicer with ^ though: ^$, ^@, ^%, ^&. The association
: with $^, @^, %^, &^ in placeholders is a bonus in my eyes because they
: are post dispatch on void invocants :)
Don't know what that means either.
'post dispatch on void' was a poor attempt to paraphrase that I see
a sub as a *very* unspecific method. That is a sub call in method style
$x.foo();
dispatches to the sub foo only if there is no other applicable method at
all. Submethods in that view are methods that are specialized on Undef of
the respective class.
BTW, is ($x,$y).foo(1,2) valid multi method invocation syntax? Note that
if there is nothing else but
sub foo ([EMAIL PROTECTED]) {...}
in scope it could be selected and called with
@bar[0] = $x;
@bar[1] = $y;
@bar[2] = 1;
@bar[3] = 2;
: The guiding theme in my line of thinking about twigils is that there's
: a void between their two chars. A "pair" of type constraint and uncaptured
: actual invocant type so to say. Well and we could capture it with
:
: method doit ( Constraint ^Actual $foo, NonInvocant $blahh ) {...}
:
: to deal have it available inside. Am I makeing sense? Which impact all
: this has an the self method discussion I don't know, but ^. and .^ come
: to mind. The former would make ^.foo a method on the current invocant
: and a bare .^ would dispatch the current method on the topic or some such.
I haven't the foggiest clue if you're making sense. And that's the
scary part.
OK, forget the part about self calls inside the method implementation and
let's look at the type variable aspect only. If I understand the concept
correctly then ^ splits the type aspect of a variable from its value aspect.
At particular moments at runtime both of them are quite unvariable! As such
they are more variable in the sense of uncertainty at compile time or
actually writing time by the programmer. If the programmer or compiler
knows more the program becomes more specific.
Now method dispatch is at its core about letting the method with the most
specific requirements handle a task. A poor err very generic implementation
strategy of method dispatch could be a sub that captures the type of its
args and then switches over them:
sub generic (^T [EMAIL PROTECTED])
{
given [EMAIL PROTECTED] # arity check
{
when 0 {...}
when 1
{
given ^T # type check
{
when Int {...}
}
}
}
}
Interesting question is how to capture the individual types inside @a?
With the arity marker in front perhaps ( * ^Sig @a )? Would +^Sig deliver
the syntactic arity of the call? In the case of +^Sig > 1 could we switch
over tuple types?
given ^Sig
{
when :(Int,Int) {...}
when :(Str,Int,*Item) {...}
}
Now my idea is that with using the method keyword instead of sub the
compiler might take over the task of fiddling with the type upfront.
method twoinvocants (Int ^X $x, Str ^Y $x, $other) {...}
and as anonymous capture with the ^$ twigil
method twoinvocants (Int ^$x, Str ^$x, $other) {...}
Actually the type capturing could explain the want function
sub foo ( $x --> ^Ret )
{
given ^Ret
{
when Str {...}
when List {...}
}
}
Mnemonically the $^ twigil means capturing any item from the caller
positionally in collation order of the identifier of the variable.
Still scary?
--
$TSa.greeting := "HaloO"; # mind the echo!
