How do you say another_sub(@_) in perl 6?
Hi,
What is the correct way to do pass through args?
In perl 5 we would do:
sub whatever {
...
nested_call(@_);
...
}
but slurpy args are undesireable, since they are lossy:
data loss - shape of input parameters is indeterminate:
sub foo ([EMAIL PROTECTED]) { ... };
my $scalar = Bah;
my @array = foo bar;
foo($scalar, @array); # gets Bah foo bar
type information loss - the types signature of the callee is
masked
A possible solution:
sub foo will call other { # type signature copied, lexical
# scope of foo changed to have 'my other = other.assuming(...)'
my $return = other();
@?PARAMS; # contains a list of positionals and nameds,
# without any flattenning, and without the shape being lost
}
And more interestingly, for generic programming:
sub foo (delegate is called) {
delegate();
}
my curried = foo.assuming(some_sub);
curried.signature; # this is already available
foo.signature; # a code, and a yadda yadda ?
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me sushi-spin-kicks : neeyah
pgpOctUZwYX55.pgp
Description: PGP signature
User defined autovivification
Today I wrote some perl 5 code that looked like this:
my %index_by_x;
my %index_by_y;
my %index_by_z;
foreach my $thing (@things){
( $index_by_x{$thing-x_value} ||=
Set::Object-new)-insert($thing);
( $index_by_y{$thing-y_value} ||=
Set::Object-new)-insert($thing);
( $index_by_z{$thing-z_value} ||=
Set::Object-new)-insert($thing);
}
I feel this code is pretty unreadable. Luke and I tossed some ideas
for how this should look in perl 6:
from #perl6:
class Foo will autovivify { Foo.new } {
...
}
my Foo %hash;
OR
my %hash will autovivify { Foo.new };
and then:
%hashkey_that_doesn't_exist.moose; # works
or with my code:
my mk_set_object = { Set::Object.new }
my %index_x will autovivify(mk_set_object);
my %index_y will autovivify(mk_set_object);
my %index_z will autovivify(mk_set_object);
or
my class ViviSet will autovivify { $?CLASS.new }
my ViviSet %index_x;
my ViviSet %index_y;
my ViviSet %index_z;
and then
for @things - $thing {
$index_x{ $thing.x_value }.insert($thing);
$index_y{ $thing.y_value }.insert($thing);
$index_z{ $thing.z_value }.insert($thing);
}
which makes the 'x_value' etc calls much more obvious, and thus good
for readability.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpT6fmyMD2Sl.pgp
Description: PGP signature
Manuthreading
While nothingmuch and I are gutting junctions and trying to find the
right balance of useful/dangerous, I'm going to propose a new way to
do autothreading that doesn't use junctions at all.
First, let me show you why I think junctions aren't good enough:
I can't extract the information that the threaded call returns to me.
For instance, I want to say:
my ($val1, $val2, $val3) = map { foo(bar, $_, baz) } 1,2,3
But without obscuring the nature of what I'm doing with that unsightly
map. That is, I want the following (using pseudosyntax):
my ($val1 | $val2 | $val3) = foo(bar, 1|2|3, baz)
But this is impossible using junctions, because the order is lost
before it comes back to my declaration.
So I propose a simple extension to the hyper syntax. The hyper meta
operator always points to the operator that is being hypered:
+ @a # prefix
@a * @b # infix
@a ++ # postfix
Now I'm going to propose a variant for circumfix:
foo(1, @a, 2);
Where the meta operator is pointing to the parentheses around the
call. Then it is easy to do my map above:
my ($val1, $val2, $val3) = foo(bar, 1,2,3, baz)
Luke
Re: Manuthreading
On Sun, Aug 28, 2005 at 09:45:02 +, Luke Palmer wrote: Where the meta operator is pointing to the parentheses around the call. Then it is easy to do my map above: my ($val1, $val2, $val3) = foo(bar, 1,2,3, baz) I think a some and of the same shape thrown into to the parameters is in order. Either of these works for me, one reminds me of explode this, then take the data and funnel it into these, and the other looks more like symmetrical shapes to me: my ($val1, $val2, $val3) = foo(bar, 1, 2, 3, baz); my ($val1, $val2, $val3) = foo(bar, 1, 2, 3, baz); but this doesn't really scale: my ( $val1, $val2, $val3, $val4 ) = foo(bar 1, 2, 3, 4 , baz) we have soome variants: 1, 3 1, 4 2, 3 2, 4 but the return of which pair goes into which value? -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!! pgp4dwboVHDL5.pgp Description: PGP signature
Re: How do you say another_sub(@_) in perl 6?
On Aug 28, 2005, at 5:52 AM, Yuval Kogman wrote:
On Sun, Aug 28, 2005 at 05:18:42 -0400, David Storrs wrote:
On Aug 28, 2005, at 5:12 AM, Yuval Kogman wrote:
On Sun, Aug 28, 2005 at 05:02:25 -0400, David Storrs wrote:
nested_call.wrap(), maybe?
It's not 100% the same thing... Wrapping is for wrapping only. This
applies to super methods, delegate methods, and so forth.
If I understand the semantics of wrap() properly, I believe you
can do everything with wrap that you want. I agree it's not the
optimal way though...for one
thing, you have to write the code inside out.
Not without breaking polymorphism, or doing creepy things like:
our method = $?CLASS.can(method).wrap {
...
call
...
};
instead of
method method {
$?SELF.SUPER::method; # what's the syntax for this, btw?
# Can't find it under s12
}
Hey, I said you /could/ do it, not that you /should/ or that it was
the best way. :
Actually, I agreed it wasn't, I was just throwing it out there as a
starting point.
On the other hand, one thing i'd like to borrow is the ability to
use 'call' for delegating subroutines:
sub foo will call(other) {
call; # just like saying other()
}
Seconded. Although it starts to get interesting when you want to
pass in multiple other()s.
--Dks
Re: User defined autovivification
On Sun, Aug 28, 2005 at 05:56:58 -0400, David Storrs wrote:
While I think your P6 code is great, I don't feel you're comparing apples to
apples. In all your P6 examples you effectively break the autovivify step
out
from the other steps. You can do that in P5 too:
To me the code below isn't broken up - it still happens in the same
loop, at the same level.
I'd like to feel like i'm describing how this hash should look
like, and from then on to let the the values pop up as necessary.
foreach my $thing (@things){
$index_by_x{$thing-x_value} ||= Set::Object-new;
$index_by_y{$thing-y_value} ||= Set::Object-new;
$index_by_z{$thing-z_value} ||= Set::Object-new;
$index_by_x{$thing-x_value}-insert($thing);
$index_by_y{$thing-y_value}-insert($thing);
$index_by_z{$thing-z_value}-insert($thing);
}
This oranges that I think perl 6 should give me allow me to say:
foreach my $thing (@things) {
$index_by_x{$thing-x_value}-insert($thing)
}
Since earlier i said this is an array of sets and now i'm saying
this is how i populate the sets.
In perl 5 it isn't possible. I've got to say here are some things,
put them in this set, and if the set is not there, make a new one.
That's exactly what I would like to change =)
IMO, this would be even clearer:
foreach my $thing (@things){
my($x,$y,$z) = ($thing-x_value, $thing-y_value, $thing- z_value);
$index_by_x{$x} ||= Set::Object-new;
$index_by_y{$y} ||= Set::Object-new;
$index_by_z{$z} ||= Set::Object-new;
$index_by_x{$x}-insert($thing);
$index_by_y{$y}-insert($thing);
$index_by_z{$z}-insert($thing);
}
This is a pet peeve of mine. For some reason I really really hate
it when something is referred to more than once, when there is
lookup involved.
I personally feel that
($index_by_z{$thing-z_value} ||= Set::Object-new)-insert($thing)
is actually cleaner than this, but that might just
be me.
Furthermore, it doesn't change the semantics:
this is an hash of sets
...
this is what a set contains
vs.
this is a hash
...
if there is no set make one, and this is what a set contains
but just the syntax.
This has the advantage of being very nonmagical, keeping code together, and
avoiding AAAD.
Arguably for plain container types autovivification is semantically
safe, at least in my opinion. I would do this for weird things (for
example, autovivification should not know the key it's autovivifying
- if you want to go that far, just tie the structure).
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgpHK8KDbxcSu.pgp
Description: PGP signature
Re: How do you say another_sub(@_) in perl 6?
On Sun, Aug 28, 2005 at 05:18:42 -0400, David Storrs wrote:
On Aug 28, 2005, at 5:12 AM, Yuval Kogman wrote:
On Sun, Aug 28, 2005 at 05:02:25 -0400, David Storrs wrote:
nested_call.wrap(), maybe?
It's not 100% the same thing... Wrapping is for wrapping only. This
applies to super methods, delegate methods, and so forth.
If I understand the semantics of wrap() properly, I believe you can do
everything with wrap that you want. I agree it's not the optimal way
though...for one
thing, you have to write the code inside out.
Not without breaking polymorphism, or doing creepy things like:
our method = $?CLASS.can(method).wrap {
...
call
...
};
instead of
method method {
$?SELF.SUPER::method; # what's the syntax for this, btw?
# Can't find it under s12
}
On the other hand, one thing i'd like to borrow is the ability to
use 'call' for delegating subroutines:
sub foo will call(other) {
call; # just like saying other()
}
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me kicks %s on the nose: neeyah!
pgpgk8s0nYZ8S.pgp
Description: PGP signature
Re: How do you say another_sub(@_) in perl 6?
On Sun, Aug 28, 2005 at 05:02:25 -0400, David Storrs wrote: nested_call.wrap(), maybe? It's not 100% the same thing... Wrapping is for wrapping only. This applies to super methods, delegate methods, and so forth. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgpDOgTN4egzn.pgp Description: PGP signature
Re: How do you say another_sub(@_) in perl 6?
On Aug 28, 2005, at 5:52 AM, Yuval Kogman wrote: oops... Can I forward our correspondence to the mailing list? Sure. I was wondering why you took it private. : --Dks
Re: Manuthreading
Luke wrote: Now I'm going to propose a variant for circumfix: foo(1, @a, 2); Where the meta operator is pointing to the parentheses around the call. Then it is easy to do my map above: my ($val1, $val2, $val3) = foo(bar, 1,2,3, baz) You're going to need to find another syntax. That one already means something else (namely, shell-like interpolating word list). Damian
Re: Manuthreading
On Sun, Aug 28, 2005 at 22:22:07 +1000, Damian Conway wrote: You're going to need to find another syntax. That one already means something else (namely, shell-like interpolating word list). Luke said he was going to sleep, so I'll point you to some chat logs instead of letting you wait for his reply: http://colabti.de/irclogger/irclogger_log/perl6?date=2005-08-28,Sunsel=281#l460 Bottom line: the aim is to change the meaning. -- () Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker /\ kung foo master: /me climbs a brick wall with his fingers: neeyah! pgpi0PoKjISUx.pgp Description: PGP signature
Re: Manuthreading
Yuval Kogman wrote: Luke said he was going to sleep, so I'll point you to some chat logs instead of letting you wait for his reply: http://colabti.de/irclogger/irclogger_log/perl6?date=2005-08-28,Sunsel=281#l460 Thanks for that. Bottom line: the aim is to change the meaning. I think that's an appalling idea. is *vastly* more valuable as interpolated word list. If you *have* to propose manuthreading, go with the previous proposal and use instead. The argument that the angles should point to the operator is spurious. People will associate inward facing with hyperization, regardless of what's being hyperized. Damian
