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
