On Wed, Oct 26, 2005 at 07:06:15PM +0200, TSa wrote: : HaloO, : : Larry Wall wrote: : >On Wed, Oct 26, 2005 at 04:59:04PM +0200, Juerd wrote: : >: Larry Wall skribis 2005-10-26 7:31 (-0700): : >: > One slightly serious ramification of the : switch is that the space : >: > is required after the colon indicating a null invocant. : : What is an invocantless method other than a sub?
It's not invocantless. I should have said "implicit". But it's implicit anyway if you leave the colon out. (And you can only leave out the invocant for the declaration of single dispatch methods anyway.) : >: > method doit (: $a, $b, $c) : >: : >: Or, we could separate it with a . instead of a :, perhaps? : : I have proposed to markup invocant parameters with a leading dot : sigil. More than one invocant either makes it a multi method or : a mono method on a more complicated type. Could do that, but again . is kind of invisible, and doesn't give us tie-breaking multiple colons. : If the zoning of parameters : is dropped however, interpersed dotted params might make Perl approach : Cecil in that respect and surpass it with combining dispatched params : with named params. That seems like a mental disaster waiting to happen to newbies. Maybe there are reasons people are avoiding Cecil... : >: This is already more or less very heavily associated with invocants : >: anyway. : : 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. : >I think a . would be too lightweight visually within the signature. : >Plus . is a postfix prefix syntactically, not a delimiter. : : How are multiple --> handled in a method sig? The standard case : of a method defined in a class puts the class type into a primary : or pre-dispatch position, or not? I mean that : : class Foo : { : method bar ($x, $y) {...} : } : : might just mean : : class Foo : { : method bar (¢Foo $?SELF --> $x, $y --> ) {...} : } : : 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. :-) : >: Hmmm... : >: : >: method .doit (...) { ... } : >: method $foo.doit () { ... } : > : >I think it would be a mistake to move the invocant outside the : >signature. We've just taken pains to move the return type *into* : >the signature. : : But the distinction between the dispatch/covariant part and the : contravariant lhs of the arrow type is difficult if we allow multiple : arrows in sigs. I would therefore like to propose anpther trait for : methods: the 'on' part. To wit: : : method doit (...) on (invocant sig) { ... } I don't see how that relates. : 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. : 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. Larry