r30205 - docs/Perl6/Spec

2010-03-26 Thread pugs-commits
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

Re: You never have privacy from your children in Perl 6

2010-03-26 Thread Carl Mäsak
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: You never have privacy from your children in Perl 6

2010-03-26 Thread Jason Switzer
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

2010-03-26 Thread Geoffrey Broadwell
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

2010-03-26 Thread pugs-commits
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.