Re: Which brackets should @a.perl use?
>> "m" == moritz writes: > > m> S02 says: > > m> "To get a Perlish representation of any object, use the .perl method. > Like > m> the Data::Dumper module in Perl 5, the .perl method will put quotes > around > m> strings, square brackets around list values," > > m> So according to this, Rakudo has it right. > m> But I think that a .perl()ification as ("blue", "light", "hayard",) > would > m> make much more sense, because simple thing like > > m> @a.push eval(@b.perl) > > m> would then DWIM. > > for your def of DWIM. i can see wanting an anon array to be pushed onto > @a building up a structure. DWIM in the sense that "eval($stuff.perl)" should behave the same as $stuff itself. since @a.push(@b) flattens @b into @a, why should I expect something different from @a.push(eval(@b.perl))? > your example is too simple to really cover > this as you could just push @b or a ref to @b (damn, i need to learn > more basic p6 syntax! :). If people want @a.push(\...@b) or @a.push([...@b]), they can just write that - and if the want to use eval + perl, they can include the brackets or backslash just as well. > a more useful example would be serializing data trees. if you dump @b > with .perl do you want the current dumper output of a anon array or your > list of values? when serializing a tree, you must get the ref version so > that is the common and default usage. your version isn't DWIMmy there at > all. Maybe we can construct something magic with slice context and captures instead? Cheers, Moritz
Re: Which brackets should @a.perl use?
Uri, On Sun, 04 Jan 2009 22:37:43 -0500, Uri Guttman wrote: > that fails with nested arrays. we don't want them to flatten. > > my $c = eval '(1, (4, 5), 3)'; > > will that work as you envision? No, but it's not what I'm proposing. A reference must Perlify as a reference, just as it does today, so that .perl doesn't destroy information by flattening where you don't want it to. Here's what I propose: my @a = 1, 2, 3; @a.perl.say; # (1, 2, 3) my $ra = @a; $ra.perl.say;# [1, 2, 3] my @b = 1, [2, 3], 4; @b.perl.say; # (1, [2, 3], 4) my $rb = @b; $rb.perl.say;# [1, [2, 3], 4] My objection to the current behaviour is that @a and $ra Perlify to the same string -- '[1, 2, 3]' -- losing the information that @a is an array and $ra is a reference to an array. Therefore, if you serialise and unserialise an array, you always get an array of a single element, containing a reference to the real data. What you get back is not what you put in. Markus
Re: Which brackets should @a.perl use?
> "ML" == Markus Laker writes: ML> Adding a single backslash before `eval' pushes an anonymous array on to ML> @b, as you envisage wanting to do: ML> # Imagine that @a.perl has produced this: ML> my $p = "('blue', 'light', 'hazard')"; ML> my @b; ML> @b.push(\eval $p); but that is manual code. what about a larger tree? >> a more useful example would be serializing data trees. if you dump @b >> with .perl do you want the current dumper output of a anon array or your >> list of values? when serializing a tree, you must get the ref version so >> that is the common and default usage. your version isn't DWIMmy there at >> all. ML> I think Perl 6's automatic reference-taking (though we don't call them ML> references any more) solves that problem for us. ML> If you say ML> my @c = eval '(1, 2, 3)'; ML> then @c has three elements. If you say ML> my $c = eval '(1, 2, 3)'; ML> then Perl constructs (if I've got the Perl 6 lingo right) an Array object ML> and stores it in $c. So the round brackets DTRT whether you're storing ML> into an array like @c or into a scalar like $c. that fails with nested arrays. we don't want them to flatten. my $c = eval '(1, (4, 5), 3)'; will that work as you envision? in perl5 with [] it works fine. i know there are contexts that flatten and others that don't. but a larger tree with assignments like that are harder to read IMO as lists inside lists are not nesting but flattening in p5 all the time. ML> We serialised an array of three elements; we got back an array containing ML> just one. Round brackets would have solved that. (Actually, we don't ML> need any brackets at all, because Perl 6's list constructor is a comma, ML> not a set of brackets. But round brackets would be no-ops, and they ML> arguably make the output more human-readable.) try that again with my example above. in p5 the structure would be this: my $c = [1, [4, 5], 3] ; how should .perl serialize that so that eval will give back the same structure? unless () are nesting and not flattening then you can't do it without a \() which is longer (and uglier IMO than []). uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Which brackets should @a.perl use?
On Sun, 04 Jan 2009 14:19:15 -0500, Uri Guttman wrote: >> "m" == moritz writes: > m> But I think that a .perl()ification as ("blue", "light", "hayard",) would > m> make much more sense, because simple thing like > > m> @a.push eval(@b.perl) > > m> would then DWIM. > > for your def of DWIM. i can see wanting an anon array to be pushed onto > @a building up a structure. That would be easily achievable if we made the change I'm suggesting, so that C<@a.perl> emitted round brackets. This is how you would clone an array, as Moritz wants to do: m...@edward:~/perl/6$ cat uri1 #!/home/msl/bin/perl6 # Imagine that @b.perl has produced this: my $p = "('blue', 'light', 'hazard')"; my @a; @a.push(eval $p); .say for @a; m...@edward:~/perl/6$ ./uri1 blue light hazard m...@edward:~/perl/6$ Adding a single backslash before `eval' pushes an anonymous array on to @b, as you envisage wanting to do: m...@edward:~/perl/6$ cat uri2 #!/home/msl/bin/perl6 # Imagine that @a.perl has produced this: my $p = "('blue', 'light', 'hazard')"; my @b; @b.push(\eval $p); .say for @b; m...@edward:~/perl/6$ ./uri2 blue light hazard m...@edward:~/perl/6$ > a more useful example would be serializing data trees. if you dump @b > with .perl do you want the current dumper output of a anon array or your > list of values? when serializing a tree, you must get the ref version so > that is the common and default usage. your version isn't DWIMmy there at > all. I think Perl 6's automatic reference-taking (though we don't call them references any more) solves that problem for us. If you say my @c = eval '(1, 2, 3)'; then @c has three elements. If you say my $c = eval '(1, 2, 3)'; then Perl constructs (if I've got the Perl 6 lingo right) an Array object and stores it in $c. So the round brackets DTRT whether you're storing into an array like @c or into a scalar like $c. I'd like to use your example of serialising and unserialising to suggest that the current behaviour is wrong: m...@edward:~/perl/6$ cat serialise #!/home/msl/bin/perl6 my @a = ; @a.perl.say; m...@edward:~/perl/6$ cat unserialise #!/home/msl/bin/perl6 my $p = =$*IN; my @a = eval $p; for (@a) { .say } m...@edward:~/perl/6$ ./serialise | ./unserialise blue light hazard m...@edward:~/perl/6$ We serialised an array of three elements; we got back an array containing just one. Round brackets would have solved that. (Actually, we don't need any brackets at all, because Perl 6's list constructor is a comma, not a set of brackets. But round brackets would be no-ops, and they arguably make the output more human-readable.) Markus
Re: Which brackets should @a.perl use?
> "m" == moritz writes: m> S02 says: m> "To get a Perlish representation of any object, use the .perl method. Like m> the Data::Dumper module in Perl 5, the .perl method will put quotes around m> strings, square brackets around list values," m> So according to this, Rakudo has it right. m> But I think that a .perl()ification as ("blue", "light", "hayard",) would m> make much more sense, because simple thing like m> @a.push eval(@b.perl) m> would then DWIM. for your def of DWIM. i can see wanting an anon array to be pushed onto @a building up a structure. your example is too simple to really cover this as you could just push @b or a ref to @b (damn, i need to learn more basic p6 syntax! :). a more useful example would be serializing data trees. if you dump @b with .perl do you want the current dumper output of a anon array or your list of values? when serializing a tree, you must get the ref version so that is the common and default usage. your version isn't DWIMmy there at all. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Free Perl Training --- http://perlhunter.com/college.html - - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
Re: Which brackets should @a.perl use?
> m...@edward:~/perl/6$ ./ap2 > @c: 3 elements: ["blue", "light", "hazard"] > @c[0]: blue > $c: 3 elements: ["blue", "light", "hazard"] > $c[0]: blue > m...@edward:~/perl/6$ > > > Is Rakudo's behaviour correct here? S02 says: "To get a Perlish representation of any object, use the .perl method. Like the Data::Dumper module in Perl 5, the .perl method will put quotes around strings, square brackets around list values," So according to this, Rakudo has it right. But I think that a .perl()ification as ("blue", "light", "hayard",) would make much more sense, because simple thing like @a.push eval(@b.perl) would then DWIM. Chhers, Moritz
Which brackets should @a.perl use?
This behaviour looks wrong to me: m...@edward:~/perl/6$ cat ap1 #!/home/msl/bin/perl6 my @a = ; my $p = @a.perl; say "\...@a: {...@a.elems} elements: $p"; say '@a[0]: ', @a[0]; my @b = eval $p; say "\...@b: {...@b.elems} elements: $p"; say '@b[0]: ',@b[0]; say '@b[0][0]: ', @b[0][0]; m...@edward:~/perl/6$ ./ap1 @a: 3 elements: ["blue", "light", "hazard"] @a[0]: blue @b: 1 elements: ["blue", "light", "hazard"] @b[0]: blue light hazard @b[0][0]: blue m...@edward:~/perl/6$ perl6 -v This is Rakudo Perl 6, revision 34744 built on parrot 0.8.2-devel for i486-linux-gnu-thread-multi. Copyright 2006-2008, The Perl Foundation. m...@edward:~/perl/6$ Because C<@a.perl> returns a string surrounded in square brackets, rather than round brackets, C produces a list containing a single element: we get one extra, unwanted level of indirection. If C<@a.perl> were to return a string surrounded in round brackets, this problem would be solved: m...@edward:~/perl/6$ cat ap2 #!/home/msl/bin/perl6 my $p = '("blue", "light", "hazard")'; my @c = eval $p; say "\...@c: {...@c.elems} elements: ", @c.perl; say '@c[0]: ', @c[0]; my $c = eval $p; say "\$c: {$c.elems} elements: ", $c.perl; say '$c[0]: ', $c[0]; m...@edward:~/perl/6$ ./ap2 @c: 3 elements: ["blue", "light", "hazard"] @c[0]: blue $c: 3 elements: ["blue", "light", "hazard"] $c[0]: blue m...@edward:~/perl/6$ Is Rakudo's behaviour correct here? Markus