Re: +$arg changed to :$arg
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
Re: +$arg changed to :$arg
On 10/27/05, TSa [EMAIL PROTECTED] wrote: 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? It's an expression in the US. Peoria is a town in the state of Illinois. It has a reputation for being conservative and a keeper of American Values (whatever that means). So, when you say something won't play in Peoria, you're saying that it's unlikely to be accepted by the masses. Rob
Re: +$arg changed to :$arg
HaloO,
Juerd wrote:
This aside, you could of course just double the colon. Or use a
semicolon.
Semicolon would give me the mnemonic of 'end of statement' seperating
the dispatched part from the checked part of the signature. Or it
reminds one of the array and hash slicing. Should we call dispatch
call or code slicing?
:( Int, Int ; Str, Num -- Foo )
A slot call would then retrieve the method from the object first
:( Item ^X -- ^X ; Foo, Bar -- Ret )
Assuming we use ^ instead of ¢ as the captured type sigil. Which
leaves the question how arrow type invocant methods relate to
non-arrow type invocant methods? Hmm, non-arrow types can always
be regarded as :( void -- ^X ) and the usual contra-variant subtyping
rule would make :( ^X -- ^X ) more specific if void were more specific
than ^X. But I think the opposite is true! That is any value can go
to void context and be ignored. In other words void is a type close to
the universal type. By the same argument any method is more specific
than subs which have void as invocant type.
I like the outcome that a free method on the same type has higher
dispatch precedence than the corresponding slot call. YMMV, though.
OTOH, the free method might not have the privileged access that a
'inside class definition' method has. But then such a outside overrider
might just delegate to the insider routine through explicit slot access.
But how does that look like? I think
method bar (Foo $x) # all params dispatched, hence ^ optional
{
say outside Foo :);
$x.Foo::bar(); # slot call
}
should do the trick. But then again, there might be no free methods
in Perl6.
I just really wouldn't like : to have two very different meanings in very
similar places.
I'm split on the issue because of the similarity to the label syntax. The
indirect object syntax is then the call continuation after the dispatch
target selection and invocants binding or some such.
--
$TSa.greeting := HaloO; # mind the echo!
Re: +$arg changed to :$arg
Larry Wall skribis 2005-10-26 6:44 (-0700): I should point out that one of the major changes in the most recent S6 is that named arguments are now marked by : rather than +, with :foo($bar) being the way to declare parameter $bar but give it the external name of foo. A + is now reserved to mark mandatory parameters, though it's redundant on positionals. A mandatory named parameter is now marked +:$nonoptionaloption. If optional parameters get ?, then why don't give mandatory parameters !? Or, if you wish: if mandatory parameters get +, then why do optional parameters not get -? # The mandatory/optional thing could even be postfix, which results in # clearer code than the stacked +:$: # # sub foo ($this!, $is!, :$mandatory!, $optional?, $really?) I do like the s/+/:/ change, though! Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: +$arg changed to :$arg
Larry~ On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: So we'd get: :@array[42] 42 = @array[1] Do you mean C :@array[42] 42 = @array[42] ? The last three forms are more arguable than the first three, especially since they probably aren't valid formal parameters. We kind of need a subscript modifier instead: @array:[42] 42 = @array[1] Same question. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -Stan Kelly-Bootle, The Devil's DP Dictionary
Re: +$arg changed to :$arg
On Wed, Oct 26, 2005 at 10:06:25AM -0400, Matt Fowles wrote: : Larry~ : : On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: : So we'd get: : : :@array[42] 42 = @array[1] : : Do you mean C :@array[42] 42 = @array[42] ? Yes. I was changing it because 42 : 1 :: foo : a, but I flubbed. : The last three forms are more arguable than the first three, especially : since they probably aren't valid formal parameters. We kind of need : a subscript modifier instead: : : @array:[42] 42 = @array[1] : : Same question. Same answer. Larry
Re: +$arg changed to :$arg
On Wed, Oct 26, 2005 at 04:02:06PM +0200, Juerd wrote: : Larry Wall skribis 2005-10-26 6:44 (-0700): : I should point out that one of the major changes in the most recent : S6 is that named arguments are now marked by : rather than +, with : :foo($bar) being the way to declare parameter $bar but give it the : external name of foo. A + is now reserved to mark mandatory : parameters, though it's redundant on positionals. A mandatory : named parameter is now marked +:$nonoptionaloption. : : If optional parameters get ?, then why don't give mandatory parameters : !? : : Or, if you wish: if mandatory parameters get +, then why do optional : parameters not get -? : : # The mandatory/optional thing could even be postfix, which results in : # clearer code than the stacked +:$: : # : # sub foo ($this!, $is!, :$mandatory!, $optional?, $really?) : : I do like the s/+/:/ change, though! That's interesting. Then we could say that = default implies ?. I think I like it. It would also ease transition of Pugs not to change the meaning of + immediately, but that's a secondary consideration. And really, + ought to mean a * but with a minimum of 1. Larry
Re: +$arg changed to :$arg
It also means you could write a prototype that looks like :(!, !, !, ?, ?) We don't need no stinkin' _. There's more than one way to not care. (I guess that means that in addition to supporting interesting values of undef, we also support interesting values of not caring...) But does that mean we can have a don't care with a default: :(!, !, !, ='foo', =42) We can even give them names without caring: :(:a!, :b!, :c!, :bar='foo', :answer=42) :-) One slightly serious ramification of the : switch is that the space is required after the colon indicating a null invocant. method doit (: $a, $b, $c) But it's only slightly serious, considering that it has a smiley. Larry
Re: +$arg changed to :$arg
On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: A mandatory named parameter is now marked +:$nonoptionaloption. Woo! :) -John
Re: +$arg changed to :$arg
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.
method doit (: $a, $b, $c)
Or, we could separate it with a . instead of a :, perhaps?
This is already more or less very heavily associated with invocants
anyway.
Hmmm...
method .doit (...) { ... }
method $foo.doit () { ... }
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: +$arg changed to :$arg
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.
: method doit (: $a, $b, $c)
:
: Or, we could separate it with a . instead of a :, perhaps?
:
: This is already more or less very heavily associated with invocants
: anyway.
I think a . would be too lightweight visually within the signature.
Plus . is a postfix prefix syntactically, not a delimiter.
: 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.
Larry
Re: +$arg changed to :$arg
Larry Wall skribis 2005-10-26 8:29 (-0700): I think a . would be too lightweight visually within the signature. Plus . is a postfix prefix syntactically, not a delimiter. If weight is the issue, @#@ should do ;) This aside, you could of course just double the colon. Or use a semicolon. I just really wouldn't like : to have two very differentmeanings in very similar places. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: +$arg changed to :$arg
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?
: 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. 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.
:
: 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.
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.
: 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) { ... }
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 :)
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.
--
$TSa.greeting := HaloO; # mind the echo!
Re: +$arg changed to :$arg
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
