Re: Which brackets should @a.perl use?

[Markus Laker]

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?

[Markus Laker]

On Sun, 04 Jan 2009 14:19:15 -0500, Uri Guttman wrote:

 m == moritz  mor...@casella.faui2k3.org 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 = blue light hazard;
@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

Which brackets should @a.perl use?

[Markus Laker]

This behaviour looks wrong to me:


m...@edward:~/perl/6$ cat ap1
#!/home/msl/bin/perl6

my @a = blue light hazard;
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, Ceval 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

Indirect objects, adverbial arguments and whitespace

[Markus Laker]

If I've got this right:

mangle $foo :a;# mangle($foo, a = 1);
mangle $foo: a;# $foo.mangle(a());

So these --

mangle $foo:a;
mangle $foo : a;

are ambiguous and, as far as I can tell from the synopses, undefined.  So
what's the rule: that indirect-object colon needs whitespace after but not
before, and adverbial colon needs whitespace before but not after?

The reason I ask is that I'm knocking up an intro to Perl 6 for C and C++
programmers.  I expect some of Perl 6's whitespace rules to trip up people
used to C++ (as they have me, in my clumsy attempts with Pugs), and I'd
like to summarise all the whitespace dwimmery in one place.

Many thanks,

Markus