r24759 - docs/Perl6/Spec
Author: pmichaud Date: 2009-01-05 08:03:29 +0100 (Mon, 05 Jan 2009) New Revision: 24759 Modified: docs/Perl6/Spec/S12-objects.pod Log: typo fix. Modified: docs/Perl6/Spec/S12-objects.pod === --- docs/Perl6/Spec/S12-objects.pod 2009-01-04 22:38:14 UTC (rev 24758) +++ docs/Perl6/Spec/S12-objects.pod 2009-01-05 07:03:29 UTC (rev 24759) @@ -251,7 +251,7 @@ (It does not warn about non-identifier strings, but such strings are likely to produce missing method errors at run time in any case.) Also, if there is whitespace around an intended C<.> concatenation, -it cannot be parsed as a method call at all; instead if fails at +it cannot be parsed as a method call at all; instead it fails at compile time because standard Perl 6 has a pseudo C<< infix:<.> >> operator that always fails at compile time.]
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
Re: "use" semantics
On 2009 Jan 4, at 8:53, Carl Mäsak wrote: Now, I can precompile the B module to PIR without a problem, but when I compile the A module, Rakudo/Parrot aborts because it runs the code in B and dies. $ parrot languages/perl6/perl6.pbc --target=pir --output=B.pir B.pm $ parrot languages/perl6/perl6.pbc --target=pir --output=A.pir A.pm Remember, remember, the fifth of November current instr.: 'die' pc 14950 (src/builtins/control.pir:204) [...] Just wondering if this is reasonable behaviour. It does confuse me a bit. I believe you'll find perl5 does the same thing. Point of "use" is to load potentially syntax/semantics-changing stuff when it will work; for active code you want a runtime load instead. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH
Re: "use" semantics
Em Dom, 2009-01-04 às 14:53 +0100, Carl Mäsak escreveu: > $ parrot languages/perl6/perl6.pbc --target=pir --output=B.pir B.pm > $ parrot languages/perl6/perl6.pbc --target=pir --output=A.pir A.pm > Remember, remember, the fifth of November > current instr.: 'die' pc 14950 (src/builtins/control.pir:204) > [...] I might be wrong, but it looks like the consequence of the reasoning I made in the other post, the problem is that, in order to import B in A, B needs to be initialized, and as B init fails, the compiling of A fails. This is not simply a rakudo bug, but rather a conceptual problem in the way BEGIN, INIT and "use" are related. daniel
Re: "use" semantics
Apologies if the point I'm about to make repeats what either Jeff or Daniel already said. I have two modules, A and B: $ cat A.pm use v6; use B; $ cat B.pm use v6; die "Remember, remember, the fifth of November"; Now, I can precompile the B module to PIR without a problem, but when I compile the A module, Rakudo/Parrot aborts because it runs the code in B and dies. $ parrot languages/perl6/perl6.pbc --target=pir --output=B.pir B.pm $ parrot languages/perl6/perl6.pbc --target=pir --output=A.pir A.pm Remember, remember, the fifth of November current instr.: 'die' pc 14950 (src/builtins/control.pir:204) [...] Just wondering if this is reasonable behaviour. It does confuse me a bit. // Carl
