[svn:perl6-synopsis] r14565 - doc/trunk/design/syn
Author: larry Date: Wed Jul 16 23:26:04 2008 New Revision: 14565 Modified: doc/trunk/design/syn/S04.pod Log: clarification suggested by Bob Rogers++ Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podWed Jul 16 23:26:04 2008 @@ -1276,8 +1276,8 @@ symbol tables visible at compile time, this binds to the compile-time view of the lexical scopes. (At run-time, the initial run-time view of these scopes is copied from the compiler's view of them, so that -initializations carry over, for instance.) At run time, whenever such -a subroutine needs to be cloned, an additional C:= binding is done +initializations carry over, for instance.) At run time, when such +a subroutine is cloned, an additional C:= binding is done at clone time to the same symbol table entry that the original C::= was bound to. (The binding is not restored on exit from the current lexical scope; this C:= binding records the Ilast cloning, not
[svn:perl6-synopsis] r14566 - doc/trunk/design/syn
Author: larry Date: Wed Jul 16 23:52:23 2008 New Revision: 14566 Modified: doc/trunk/design/syn/S04.pod Log: suggestion from moritz++ that POST blocks be allowed to see the return value Modified: doc/trunk/design/syn/S04.pod == --- doc/trunk/design/syn/S04.pod(original) +++ doc/trunk/design/syn/S04.podWed Jul 16 23:52:23 2008 @@ -14,7 +14,7 @@ Date: 19 Aug 2004 Last Modified: 16 July 2008 Number: 4 - Version: 67 + Version: 68 This document summarizes Apocalypse 4, which covers the block and statement syntax of Perl. @@ -1060,6 +1060,14 @@ before CBEGIN, CCHECK, or CINIT, since those are done at compile or process initialization time). +For blocks such as CKEEP and CPOST that are run when exiting a +scope normally, the return value (if any) from that scope is available +as the current topic. (It is presented as a CCapture object.) +The topic of the outer block is still available as C OUTER::$_ . +Whether the return value is modifiable may be a policy of the block +in question. In particular, the return value should not be modified +within a CPOST block, but a CLEAVE block could be more liberal. + =head1 Statement parsing In this statement:
Re: $foo[0][0] versus $foo[0;0]
On Wed, Jul 16, 2008 at 10:04:03AM -0700, Larry Wall wrote: On Sun, Jul 13, 2008 at 02:17:10PM -0500, Adrian Kreher wrote: : Hi, : : I'm reviewing the tests in S09, and the file : t/spec/S02-builtin_data_types/multi_dimensional_array.t uses the [0][0] : indexing format interchangeably with [0;0]. : : These two formats mean two different things, correct? The [0][0] form isn't : mentioned much in the spec, nor is [0;0] or if they interact somehow. I think they should come out to meaning the same thing, though the [0][0] form may be less efficient if it has to temporarily construct a slice of the next dimension of the array. On the other hand, a naïve implementation of the multidimensional subscripter might just do the same thing internally for the semicolon, so it could be a wash. Would it be counter-productive to specify that the implementation is allowed to compile time optimise [$a][$b] etc to [$a;$b] etc? I'm assuming that it is allowed for the implementation of a multidmentional array to have different semantics for [$a][$b] and [$a;$b], but that seems to violate good sense, much like overloading a class in Perl 5 (or any other language) such that (++$a) and ($a + 1) are not the same. Nicholas Clark
[svn:perl6-synopsis] r14567 - doc/trunk/design/syn
Author: larry Date: Thu Jul 17 10:57:24 2008 New Revision: 14567 Modified: doc/trunk/design/syn/S09.pod Log: Equivalence of cascaded and semicolon subscript forms suggested by nick++ Modified: doc/trunk/design/syn/S09.pod == --- doc/trunk/design/syn/S09.pod(original) +++ doc/trunk/design/syn/S09.podThu Jul 17 10:57:24 2008 @@ -12,9 +12,9 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 13 Sep 2004 - Last Modified: 27 May 2008 + Last Modified: 17 July 2008 Number: 9 - Version: 27 + Version: 28 =head1 Overview @@ -776,6 +776,27 @@ @x[0;1;42] +=head1 Cascaded subscripting of multidimensional arrays + +For all multidimensional array types, it is expected that cascaded subscripts: + +@x[0][1][42] +@x[0..10][1,0][1..*:by(2)] + +will either fail or produce the same results as the equivalent +semicolon subscripts: + +@x[0;1;42] +@x[0..10; 1,0; 1..*:by(2)] + +Built-in array types are expected succeed either way, even if +the cascaded subscript form must be implemented inefficiently by +constructing temporary slice objects for later subscripts to use. +(User-defined types may choose not to support the cascaded form, but +if so, they should fail rather than providing different semantics.) +As a consequence, for built-in types of declared shape, the appropriate +number of cascaded subscripts may always be optimized into the +semicolon form. =head1 The semicolon operator
