r30205 - docs/Perl6/Spec
Author: lwall
Date: 2010-03-26 08:38:16 +0100 (Fri, 26 Mar 2010)
New Revision: 30205
Modified:
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S03-operators.pod
docs/Perl6/Spec/S05-regex.pod
docs/Perl6/Spec/S06-routines.pod
docs/Perl6/Spec/S12-objects.pod
Log:
[specs] Make it clear that pairs are *not* related to subscripts, but the
corresponding fatarrow semantics in particular, name extenders are just
strings or list of strings, properly indicated by :<> or :() in most cases
(this includes all operator names). Forbid name extension using :{}, and
since names may no longer be extended with :{}, we can free up that notation
for supplying a closure as a first argument to a method without an intervening
space. (We can't also get rid of the colon, or it's a hash subscript.)
Modified: docs/Perl6/Spec/S02-bits.pod
===
--- docs/Perl6/Spec/S02-bits.pod2010-03-26 04:10:22 UTC (rev 30204)
+++ docs/Perl6/Spec/S02-bits.pod2010-03-26 07:38:16 UTC (rev 30205)
@@ -13,8 +13,8 @@
Created: 10 Aug 2004
-Last Modified: 12 Mar 2010
-Version: 208
+Last Modified: 26 Mar 2010
+Version: 209
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -2919,14 +2919,14 @@
infix:<+>
infix:<<+>>
infix:«+»
-infix:['+']
+infix:('+')
Despite the appearance as a subscripting form, these names are resolved
not at run time but at compile time. The pseudo-subscripts need not
be simple scalars. These are extended with the same two-element list:
infix:
-infix:['??','!!']
+infix:('??','!!')
An identifier may be extended with multiple named identifier
extensions, in which case the names matter but their order does not.
@@ -3280,10 +3280,10 @@
16 => $somevalue:16($somevalue) radix conversion function
'' => $x:($x) arglist or signature literal
'' => ($x,$y) :($x,$y)arglist or signature literal
-'' =>:identifier extension
-'' => «x» :«x»identifier extension
-'' => [$x,$y] :[$x,$y]identifier extension
-'' => { .say } :{ .say } adverbial block
+'' =>:name extension
+'' => «x» :«x»name extension
+'' => ($x,$y) :($x,$y)name extension
+'' => { .say } :{ .say } adverbial block (not allowed on names)
All of the adverbial forms (including the normal ones with
identifier keys) are considered special tokens and are recognized
@@ -3314,6 +3314,22 @@
standard Perl 6 grammar knows the current set of infix operators,
for instance.)
+Only identifiers that produce a list of one or more values (preferably
+strings) are allowed as name extensions; in particular, closures
+do not qualify as values, so the C<:{...}> form is not allowed as a
+name extender. In particular, this frees up the block form after a method
+name, so it allows us to parse a block as a method argument:
+
+@stuff.sort:{ +$_ }.map:{ $_ * 2 }
+
+These might look like it is using pairs, but it is really equivalent to
+
+@stuff.sort: { +$_ }.map: { $_ * 2 }
+
+and the colons are not introducing pairs, but rather introducing
+the argument list of the method. (In any other location, C<:{...}>
+would be taken as a pair mapping the null key to a closure.)
+
Either fatarrow or adverbial pair notation may be used to pass
named arguments as terms to a function or method. After a call with
parenthesized arguments, only the adverbial syntax may be used to pass
@@ -3327,8 +3343,9 @@
Note that (as usual) the C<{...}> form (either identifier-based
or special) can indicate either a closure or a hash depending on
-the contents. It does I always indicate a subscript despite
-being parsed as one. (The function to which it is passed can I
+the contents. It does I indicate a subscript, since C<:key{}> is
+really equivalent to C {}>, and the braces are not behaving
+as a postfix at all. (The function to which it is passed can I
the value as a subscript if it chooses, however.)
Note also that the C<< >> form is not a subscript and is
@@ -4414,16 +4431,16 @@
category: prefix:<+>
circumfix:<[ ]> [ @x ]
dotty:<.=> $obj.=method
-infix_circumfix_meta_operator:{'»','«'} @a »+« @b
+infix_circumfix_meta_operator:('»','«') @a »+« @b
infix_postfix_meta_operator:<=> $x += 2;
infix_prefix_meta_operator: $x !~~ 2;
infix:<+> $x + $y
package_declarator: role Foo;
postcircumfix:<[ ]> $x[$y] or $x.[$y]
-postfix_prefix_meta_operator:{'»'} @array »++
+postfix_prefix_meta_operat
[perl #73806] if() not parsed as sub call; should do, and emit a warning
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #73806]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73806 >
10:15 <@moritz_> rakudo: my @b= 5, 1, 2; if(@b>2) {say 'yes';}
10:15 <+p6eval> rakudo db0f85: OUTPUT«yes»
10:15 <@moritz_> WOAH THERE
10:16 <@moritz_> std: my @b= 5, 1, 2; if(@b>2) {say 'yes';}
10:16 <+p6eval> std 30196: OUTPUT«===SORRY!===if() interpreted as function
call at line 1; please use whitespace instead of
parensUnexpected block in infix position (two terms in
a row)
10:15 < cat> moiat /tmp/k2Uj3vzit0 line 1:--> my @b= 5, 1, 2; if(@b>2)
⏏{say 'yes';}
Rakudo should follow STD here.
[perl #73808] Providing a list of attributes to a single 'has' leads to IMCC syntax errors
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #73808]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73808 >
./perl6 -e 'class A { has ($!a, $!b) }'
error:imcc:syntax error, unexpected ')' (')')
in file 'EVAL_1' line 85
Not good...
(This is triggered by t/spec/S12-class/attributes.t, but not exercised
there - somehow the test harness doesn't catch those errors)
[perl #73818] Test::is flattens arguments
# New Ticket Created by "Mark J. Reed" # Please include the string: [perl #73818] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=73818 > This test currently passes: is [1,2,3,4], [[1,2],[3,4]] and I'm thinking it probably should not. -- Mark J. Reed
[perl #73816] Zip flattens result
# New Ticket Created by "Mark J. Reed" # Please include the string: [perl #73816] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=73816 > > my @a = (1,2) Z (3,4); say @a.perl [1, 3, 2, 4] Per S03, that should be [[1,3],[2,4]]. Tried to write a test case for this, but that attempt was complicated by the fact that this test: is [[1,2],[3,4]], [1,2,3,4] currently passes. Opening a separate bug for that. -- Mark J. Reed
Re: You never have privacy from your children in Perl 6
Carl (>), Darren (>>):
>> I didn't get it to trust me, though:
>>
>> pugs: class A { has $!foo }; class B { trusts A; method bar(A
>> $a) { say $a!foo } }; B.new.bar(A.new(:bar(42)))
>> pugs: OUTPUT«»
>>
>> Either it bitrotted or I'm using it wrong.
>
> You're using it wrong. You need to put 'trusts B;' in A in order for B to
> see A's privates. I hope it is obvious why this is the case. -- Darren
> Duncan
Aye, my mistake. Apparently the syntax I used to try to get at the
private attribute would instead have called a private method. So much
for rooting things in the concreteness of an implementation. ;)
// Carl
Re: [perl #73818] Test::is flattens arguments
Yes, I found that after I submitted the bug. I still find it surprising that differently-nested structures stringify to the same thing, and the names seem a bit misleading, since stringification is still "deep" (it has to recurse into the structure to pull out all the leaves). I'm wondering if there isn't a niche for a comparator that is still "shallow" in that it doesn't recurse past the top-level components of an aggregate, but still considers lists of differently-typed top-level items to be different. Thanks for the followup. On Fri, Mar 26, 2010 at 5:55 AM, Moritz Lenz via RT wrote: > is() does string comparison, and I see no bug in there. > > If you want structural equivalence testing, use is_deeply instead. > -- Mark J. Reed
[perl #73836] [BUG] Cannot do infix: on two item operands in Rakudo
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #73836]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=73836 >
rakudo: say 2 Z 3
rakudo db0f85: OUTPUT«No applicable candidates found to
dispatch to for 'infix:'. Available candidates are::(Iterable
$a-iterable, Iterable $b-iterable)current instr.: '_block14' pc 29
(EVAL_1:0)»
there seems to be only one candidate, yes
masak: have you seen this? :-)
Probably needs one more candidate.
multi infix:($a, $b) { &infix:($a.list, $b.list) }
That's what we've done for hypers etc.
moritz_: nope, hadn't seen that one.
* masak submits rakudobug
Build Rakudo with Distutils
Find attached a script 'setup.nqp' for building/testing Rakudo. The library 'disutils' is shipped with Parrot. See https://trac.parrot.org/parrot/browser/trunk/runtime/parrot/library/distutils.pir This library removes the dependences with Makefile & various make utilities, and remove the configure step. And this library simplifies the job of packager, for example $ parrot-nqp setup.nqp bdist --version 2010.99 produces an Windows installer on Windows and a RPM on Linux. The library 'distutils' is well integrated with Plumage (the Parrot ecosystem). The classic incantations are : $ parrot-nqp setup.nqp update $ parrot-nqp setup.nqp clean $ parrot-nqp setup.nqp build # build is the default target $ parrot-nqp setup.nqp test # or coretest $ parrot-nqp setup.nqp spectest $ parrot-nqp setup.nqp spectest_smolder # or smoke François (Note: I am not a Rakudo committer) setup.nqp Description: Binary data
Re: You never have privacy from your children in Perl 6
On Fri, Mar 26, 2010 at 7:16 AM, Carl Mäsak wrote: > You're using it wrong. You need to put 'trusts B;' in A in order for B to > > see A's privates. I hope it is obvious why this is the case. -- Darren > > Duncan > > Aye, my mistake. Apparently the syntax I used to try to get at the > private attribute would instead have called a private method. So much > for rooting things in the concreteness of an implementation. ;) I'm assuming Moritz is right in that Rakudo is currently leaky with private members (such as $!b in Masak's example), and I agree that truly private members has great value. It was unclear to me from the discussion so far whether this is the case for Perl 6. Also, this discussion of "trusts" piqued my interest; this sounds like a bad idea. Those of you who have worked extensively with C++ should bemoan "trusts" as much as friend classes. They break encapsulation for special cases, almost encouraging truly hideous object models that ultimately become purely public (painful on a large scale). I can't stress enough that if these are of similar nature, "trusts" should be removed. I'm all ears though if someone knows of a reason why they're more useful than onerous. -Jason "s1n" Switzer
Re: r30205 - docs/Perl6/Spec
On Fri, 2010-03-26 at 08:38 +0100, pugs-comm...@feather.perl6.nl wrote:
> .doit: { $^a <=> $^b } # okay
> .doit(): { $^a <=> $^b }# okay
> .doit(1,2,3): { $^a <=> $^b } # okay
> +.doit(1,2,3): { $^a <=> $^b } # okay
> +.doit:{ $^a <=> $^b } # okay
> +.doit():{ $^a <=> $^b }# okay
> +.doit(1,2,3):{ $^a <=> $^b } # okay
> +.doit(1,2,3):{ $^a <=> $^b } # okay
My eyes must be playing tricks on me -- I can't see the difference
between the last two lines in each of the above blocks. What am I
missing?
-'f
r30211 - docs/Perl6/Spec
Author: lwall
Date: 2010-03-27 01:59:04 +0100 (Sat, 27 Mar 2010)
New Revision: 30211
Modified:
docs/Perl6/Spec/S12-objects.pod
Log:
[S12] pasto noticed by goeff++
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2010-03-26 15:44:34 UTC (rev 30210)
+++ docs/Perl6/Spec/S12-objects.pod 2010-03-27 00:59:04 UTC (rev 30211)
@@ -459,7 +459,6 @@
.doit: { $^a <=> $^b } # okay
.doit(): { $^a <=> $^b }# okay
.doit(1,2,3): { $^a <=> $^b } # okay
-.doit(1,2,3): { $^a <=> $^b } # okay
Normally a space is required after the colon to disambiguate what
follows from from a pair that extends the previous name. However,
@@ -471,7 +470,6 @@
.doit:{ $^a <=> $^b } # okay
.doit():{ $^a <=> $^b }# okay
.doit(1,2,3):{ $^a <=> $^b } # okay
-.doit(1,2,3):{ $^a <=> $^b } # okay
These are parsed as there were a space there, so the argument list may
continue if the closure is followed by a comma.
