Re: "our" methods?
John M. Dlugosz 提到:
> In S29, there are definitions like
>our Capture method shape (@array: ) is export
> But in S12 there is no mention as to what an "our" method is. It states that
> "my" is used to make private methods, and "^" to make class methods.
> I think this is a doc relic and should be fixed globally in that file.
S02/"Return types":
"
If a subroutine is not explicitly scoped, it belongs to the current
namespace (module, class, grammar, or package), as if it's scoped with
the C scope modifier. Any return type must go after the name:
"
So this line:
our Capture method shape (@array: ) is export
is really the same as:
method shape (@array: ) of Capture is export
The prefixing of "our" is there to make the return ("of") type stand out.
Cheers,
Audrey
S09 editorial fixes
I just finished another pass on S09, and in this posting I note editorial
issues with the file that can easily be corrected. This is as opposed to
subjects for deep discussion, which I'll save for later and individual posts.
= on Mixing subscripts
"Within a C<.[]> indexing operation..."
Why the dot? The examples don't use a dot, and this makes it sound like the
dot is involved and that is confusing. I see that C<.{}> was also mentioned
earlier.
= on PDL support
The term "PDL" is never defined. A one-sentence introduction and href would be
nice.
I first encountered it elsewhere in the docs, and did not know what it was. I
found it quickly on Wikipedia. So to be more constructive, I'd suggest,
"PDL (Perl Data Language, see
L) is an extension in Perl 5
with a significant user base. The following sections discuss how PDL may look
in Perl 6. This may inspire certain support in the core language, and at least
shows what needs to be possible to achieve in an extension."
= on The semicolon operator
"Another thing that's not going to fly easily is simply dropping out terms"
to the end of the section.
That is out of place. The transition is wrong, and it does not express
something that is unique to this topic. I think it is a relic.
= on Parallelized parameters and autothreading
use autoindex;
do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
Shouldn't those be semicolons? Ditto for subsequent examples.
Also, what does the "do" do? I think it is only meaningful if there was
something using this block's return value. I suspect it is a relic of p5
notation.
= on Autovivification
"Note that assignment implicitly binds a copy..."
Does assignment do binding? I thought it would change the value in the
existing container using its assignment function, not create a new container!
Is this just poor wording?
Yes, the same section concludes, "Assignment doesn't look like binding, but
consider that it's really calling some kind of underlying set method on the
container, which must be mutable in order to change its contents."
I suggest changing to read "implicitly makes a copy..."
--John
Re: S09 editorial fixes
John M. Dlugosz 提到:
> = on Parallelized parameters and autothreading
>
> use autoindex;
> do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
>
> Shouldn't those be semicolons? Ditto for subsequent examples.
> Also, what does the "do" do? I think it is only meaningful if there was
> something using this block's return value. I suspect it is a relic of p5
> notation.
No, something more subtle is going on -- the "do STATEMENT" notation
sees a stand-alone block in statement position, so it's automatically
called with no arguments.
Here is a rewrite of that section starting from line 1044 onward.
Sanity-check before I check it in?
"
In the abstract (and often in the concrete), this puts an implicit
loop around the block of the closure that visits all the possible
subscript values for that dimension (unless the parameter is actually
supplied to the closure, in which case the supplied value is used as
the slice subscript instead).
This implicit loop is assumed to be parallelizable.
So to write a typical tensor multiplication:
Cijkl = Aij * Bkl
you can simply call a closure with no arguments, allowing the C
pragma to fill in the defaults:
use autoindex;
-> $i, $j, $k, $l { @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l] }();
or you can use the C syntax to execute a stand-alone closure,
which also implicit loops:
use autoindex;
do -> $i, $j, $k, $l {
@c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l]
}
or even use placeholder variables instead of a parameter list:
use autoindex;
do { @c[$^i; $^j; $^k; $^l] = @a[$^i; $^j] * @b[$^k; $^l] };
That's almost pretty.
"
Re: S09 editorial fixes
Audrey Tang 提到:
> John M. Dlugosz 提到:
>
>> = on Parallelized parameters and autothreading
>>
>> use autoindex;
>> do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
>>
>> Shouldn't those be semicolons? Ditto for subsequent examples.
>> Also, what does the "do" do? I think it is only meaningful if there was
>> something using this block's return value. I suspect it is a relic of p5
>> notation.
>
> No, something more subtle is going on -- the "do STATEMENT" notation
> sees a stand-alone block in statement position, so it's automatically
> called with no arguments.
Er, sorry, that wasn't entirely correct. :-)
It's actually using the "do BLOCK" form, which implicitly calls the
block once, with no arguments, as defined in S04/"The do-once loop".
So the paragraph that mentioned "do STATEMENT" in my previous mail
should instead read:
"
or you can use the C syntax (see L) to
call that closure, which also implicit iterates:
"
Cheers,
Audrey
Re: S09 editorial fixes
On Wed, Apr 02, 2008 at 11:02:37PM +0800, Audrey Tang wrote: : Sanity-check before I check it in? I'm probably not the best person to ask about *sanity*, but it looks pretty darn good to me. :) Larry
[svn:perl6-synopsis] r14532 - doc/trunk/design/syn
Author: audreyt
Date: Wed Apr 2 08:56:38 2008
New Revision: 14532
Modified:
doc/trunk/design/syn/S09.pod
Log:
* S09/"Parallelized parameters and autothreading":
@a[$i, $j] etc in examples should read @a[$i; $j] instead.
Also, clarify that "do -> { ... }" is intentionally calling the
block via the do-once loop syntax, because a pointy sub at that
point wouldn't trigger the statement-level-bare-block-autocall
rule.
Reported by: John M. Dlugosz
Modified: doc/trunk/design/syn/S09.pod
==
--- doc/trunk/design/syn/S09.pod(original)
+++ doc/trunk/design/syn/S09.podWed Apr 2 08:56:38 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 13 Sep 2004
- Last Modified: 17 Mar 2008
+ Last Modified: 2 Apr 2008
Number: 9
- Version: 24
+ Version: 25
=head1 Overview
@@ -1044,28 +1044,34 @@
In the abstract (and often in the concrete), this puts an implicit
loop around the block of the closure that visits all the possible
subscript values for that dimension (unless the parameter is actually
-supplied to the closure, in which case that is what is used as the
-slice subscript). This implicit loop is assumed to be parallelizable.
+supplied to the closure, in which case the supplied value is used as
+the slice subscript instead).
+
+This implicit loop is assumed to be parallelizable.
So to write a typical tensor multiplication:
Cijkl = Aij * Bkl
-you can just write this:
+you can simply call a closure with no arguments, allowing the C
+pragma to fill in the defaults:
use autoindex;
-do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
-
-or equivalently:
+-> $i, $j, $k, $l { @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l] }();
--> $i, $j, $k, $l { @c[$i, $j, $k, $l] = @a[$i, $j] * @b[$k, $l] }();
-
-or even:
+or you can use the C syntax (see L) to
+call that closure, which also implicitly iterates:
+use autoindex;
do -> $i, $j, $k, $l {
-@c[$i, $j, $k, $l] = @a[$i, $j] * @b[$k, $l]
+@c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l]
}
+or even use placeholder variables instead of a parameter list:
+
+use autoindex;
+do { @c[$^i; $^j; $^k; $^l] = @a[$^i; $^j] * @b[$^k; $^l] };
+
That's almost pretty.
It is erroneous for an unbound parameter to match multiple existing array
Re: S09 editorial fixes
John M. Dlugosz 提到:
> But about your answer, "automatically called with no arguments". Isn't
> that what a bare closure normally does anyway? Say, I introduced extra
> {} just for scoping or naming the block, where a statement is expected.
>
> foo;
> bar;
> { my $temp= foo; bar(temp); } #forget about $temp.
Correct, but a pointy "-> $i {...}" is not bare, and neither is blocks
with placeholders such as "{ $^i }".
In fact, the latter is currently an error in Pugs:
$ ./pugs -e '{$^i}'
*** Blocks with implicit params cannot occur at statement level
at -e line 1, column 1
The relevant paragraph is S04/"The do-once loop":
"
Although a bare block is no longer a do-once loop, it still executes
immediately as in Perl 5, as if it were immediately dereferenced with
a C<.()> postfix, so within such a block C refers to the
scope surrounding the block. If you wish to return a closure from a
function, you must use an explicit prefix such as C or C
or C<< -> >>. (Use of a placeholder parameter is deemed insufficiently
explicit because it's not out front where it can be seen. You can, of
course, use a placeholder parameter if you also use C.)
"
I guess the wording in the last parenthesized parens is insufficiently
explicit, and maybe we should change it to say that it's really a syntax
error to use placeholder blocks in statement positions. Sounds reasonable?
Cheers,
Audrey
[svn:perl6-synopsis] r14533 - doc/trunk/design/syn
Author: audreyt Date: Wed Apr 2 09:13:06 2008 New Revision: 14533 Modified: doc/trunk/design/syn/S09.pod Log: * S09/Autovivification: Change the wording "assignment implicitly binds a copy" to "assignment is treated the same way as binding to a copy container", because assignment and binding are two orthogonal concepts. Reported by: John M. Dlugosz Modified: doc/trunk/design/syn/S09.pod == --- doc/trunk/design/syn/S09.pod(original) +++ doc/trunk/design/syn/S09.podWed Apr 2 09:13:06 2008 @@ -14,7 +14,7 @@ Date: 13 Sep 2004 Last Modified: 2 Apr 2008 Number: 9 - Version: 25 + Version: 26 =head1 Overview @@ -1168,10 +1168,14 @@ Autovivification will only happen if the vivifiable path is bound to a read-write container. Value extraction (that is, binding to a readonly -or copy container) does not autovivify. (Note that assignment implicitly -binds a copy, so it does not autovivify its right side.) Any mention of -an expression within a C delays the autovivification decision -to binding time. (Binding to a "ref" parameter also defers the decision.) +or copy container) does not autovivify. + +Note that assignment is treated the same way as binding to a copy container, +so it does not autovivify its right side either. + +Any mention of an expression within a C delays the autovivification +decision to binding time. (Binding to a "ref" parameter also defers the +decision.) This is as opposed to Perl 5, where autovivification could happen unintentionally, even when the code looks like a non-destructive test:
Re: S09 editorial fixes
John M. Dlugosz 提到:
> I just finished another pass on S09, and in this posting I note
> editorial issues with the file that can easily be corrected. This is as
> opposed to subjects for deep discussion, which I'll save for later and
> individual posts.
>
> = on Mixing subscripts
> "Within a C<.[]> indexing operation..."
> Why the dot? The examples don't use a dot, and this makes it sound like the
> dot is involved and that is confusing. I see that C<.{}> was also mentioned
> earlier.
The dot is there to signify that we're talking about postcircumfix:<[
]>, the indexing function, instead of circumfix:<[ ]>, the array
construction function. I guess we can say "Within a postcircumfix C<[]>
indexing operation", but I'm not sure it's clearer.
> = on The semicolon operator
>
> "Another thing that's not going to fly easily is simply dropping out
> terms" to the end of the section.
>
> That is out of place. The transition is wrong, and it does not express
> something that is unique to this topic. I think it is a relic.
It's there to explain that why we use an explicit Whatever Asterisk:
0..* :by(2)
instead of simply dropping out the right-hand term:
0.. :by(2)
Because :by(2) in term position is a pair constructor, not a named
argument in the current expression.
Suggestions welcome on how to make the transition more smooth, though. :-)
Cheers,
Audrey
Re: Question on your last change to S02
Hmm, both of you are kinda going off on a tangent here. The meaning of the Whatever represented by * is neither something that gets magically interpreted before postcircumfix:<[ ]>, nor is it a compile-time rewrite. Context is supplied by binding in Perl 6, and the binding happens within .[]. It's the fact that the parameter within .[] is declared with @@ that causes it to bind as a slice, so that each dimension of the argument comes in as a single array element. (By the way, you'll note the utility of being able to talk about a postfix by saying .[], which is one of the reasons we allow the optional dot there. :) Now, you'll ask how *-2 works. If you do math on a Whatever object, it just remembers that offset until the Whatever is given a meaning, which, in this case, is delayed until the subscripting operator decides what the size of the next dimension is. At a lower level than the subscript it probably ends up being some kind of a fallback multi that binds to a Whatever type for that dimension, as the subscripting operator processes through each dimension in its @@ array. Or maybe it's just a case in a switch. In any case, the subscriptor knows the next "top" dimension, so it can know the size at that point. At compile time the subscript parser really only knows how many dimensions are referred to by how many semicolons there are. A subscript that is explicitly cast to @@ is known to be multidimensional, and interpolates the returned List of Capture into the outer List of Capture, and the compiler can make no compile-time assumptions about how far down the dimension list any subsequent dimensional sublists will end up. However, at least we can hope that @@ x() specifies the exact number of dimensions to interpolate at run time. One additional variant of Whatever is **, which represents an arbitrary number of dimensions. In essence, it's an instruction to the subscripting logic as it's processing top-down through the dimensions that it has to reverse its logic and count the rest of the subscripts bottom-up from the end of its @@ bound list instead of from the beginning. As such, there can really only be one such reversal, so we limit ourselves to a single ** argument representing an arbitrary number of dimensions to skip over, assuming the rest of the dimensions are end-anchored, as it were. Larry
Re: "our" methods?
I understand. Thank you.
This ought to be mentioned in S12. Perhaps after the treatment on "my",
explain that "our" is the default, but saying it explicitly allows the
return type to be first.
--John
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
> John M. Dlugosz 提到:
>
>> In S29, there are definitions like
>>our Capture method shape (@array: ) is export
>> But in S12 there is no mention as to what an "our" method is. It states
>> that "my" is used to make private methods, and "^" to make class methods.
>> I think this is a doc relic and should be fixed globally in that file.
>>
>
> S02/"Return types":
>
> "
> If a subroutine is not explicitly scoped, it belongs to the current
> namespace (module, class, grammar, or package), as if it's scoped with
> the C scope modifier. Any return type must go after the name:
> "
>
> So this line:
>
> our Capture method shape (@array: ) is export
>
> is really the same as:
>
> method shape (@array: ) of Capture is export
>
> The prefixing of "our" is there to make the return ("of") type stand out.
>
> Cheers,
> Audrey
>
>
>
Re: S09 editorial fixes
On Thu, Apr 03, 2008 at 12:04:47AM +0800, Audrey Tang wrote: : I guess the wording in the last parenthesized parens is insufficiently : explicit, and maybe we should change it to say that it's really a syntax : error to use placeholder blocks in statement positions. Sounds reasonable? Yes, unless we decide we need something like that for list comprehensions. Maybe looping modifiers allow placeholders in what would otherwise be an error... Larry
[svn:perl6-synopsis] r14534 - doc/trunk/design/syn
Author: larry
Date: Wed Apr 2 09:43:45 2008
New Revision: 14534
Modified:
doc/trunk/design/syn/S02.pod
Log:
Some fossil unspace verbiage cleaned up on recommendation of John M. Dlugosz++
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Apr 2 09:43:45 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 10 Aug 2004
- Last Modified: 31 Mar 2008
+ Last Modified: 2 Apr 2008
Number: 2
- Version: 131
+ Version: 132
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -224,23 +224,23 @@
Perl requires an absence of whitespace between a noun and a postfix
operator, using unspace lets you line up postfix operators:
-%hash\ .{$key}
-@array\ .[$ix]
-$subref\.($arg)
+%hash\ {$key}
+@array\ [$ix]
+$subref\($arg)
-As a special case to support the use above, a backslashed dot where
+As a special case to support the use above, a backslash where
a postfix is expected is considered a degenerate form of unspace.
Note that whitespace is not allowed before that, hence
-$subref \.($arg)
+$subref \($arg)
is a syntax error (two terms in a row). And
-foo \.($arg)
+foo \($arg)
-will be parsed as a list operator with an argument:
+will be parsed as a list operator with a C argument:
-foo(\$_.($arg))
+foo(\($arg))
However, other forms of unspace may usefully be preceded by whitespace.
(Unary uses of backslash may therefore never be followed by whitespace
@@ -297,8 +297,10 @@
OUTPUT
Note that this is one of those cases in which it is fine to have
-whitespace before the unspace. (Note also that the example above
-is not meant to spec how the test suite works. :)
+whitespace before the unspace, since we're only trying to suppress
+the newline transition, not all whitespace as in the case of postfix
+parsing. (Note also that the example above is not meant to spec how
+the test suite works. :)
=item *
@@ -346,6 +348,8 @@
$x.++
+$x\ ++
+
$x\ .++
$x\#( comment ).++
@@ -1481,11 +1485,13 @@
&foo($arg1, $arg2);
-Whitespace is not allowed before the parens, but there is a
-corresponding C<.()> operator, plus the "unspace" forms that allow
-you to insert optional whitespace and comments between the backslash
-and the dot:
+Whitespace is not allowed before the parens because it it is parsed as
+a postfix. As with any postfix, there is also a corresponding C<.()>
+operator, and you may use the "unspace" form to insert optional
+whitespace and comments between the backslash and either of the
+postfix forms:
+&foo\ ($arg1, $arg2);
&foo\ .($arg1, $arg2);
&foo\#[
embedded comment
@@ -1838,7 +1844,7 @@
MyType::<$foo>
MyType.::.{'$foo'} # same thing with dots
-MyType\ .::\ .{'$foo'} # same thing with unspaces
+MyType\ ::\ {'$foo'}# same thing with unspaces
(Directly subscripting the type with either square brackets or curlies
is reserved for various generic type-theoretic operations. In most other
@@ -2939,9 +2945,9 @@
pairs. To align values of option pairs, you may use the
"unspace" postfix forms:
-:longkey\ .($value)
-:shortkey\ .
-:fookey\ .{ $^a <=> $^b }
+:longkey\ ($value)
+:shortkey\
+:fookey\ { $^a <=> $^b }
These will be interpreted as
Re: S09 editorial fixes
Larry Wall 提到:
Yes, unless we decide we need something like that for list
comprehensions. Maybe looping modifiers allow placeholders in what
would otherwise be an error...
Sure. How about this:
"
Use of a placeholder parameter in statement-level blocks triggers a
syntax error, because the parameter is not out front where it can be
seen. However, it's not an error when prefixed by a C, or when
followed by a statement modifier:
# Syntax error: statement-level placeholder block
{ say $^x };
# Not an syntax error, though $x doesn't get the argument it wants
do { say $^x };
# Not an error at all
{ say $^x } for 1..10;
"
I do find it interesting that, because "any block just inside a left
parenthesis is immediately called like a bare block", we have:
my $x = {1+1}; # $x is a Code
my $y = ({1+1});# $y is 2!
Is that correct?
Cheers,
Audrey
[svn:perl6-synopsis] r14535 - doc/trunk/design/syn
Author: larry
Date: Wed Apr 2 09:49:48 2008
New Revision: 14535
Modified:
doc/trunk/design/syn/S02.pod
Log:
Another fix suggested by John M. Dlugosz++, whose name I can almost spell now.
Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podWed Apr 2 09:49:48 2008
@@ -1356,10 +1356,14 @@
Subscripts now consistently dereference the container produced by
whatever was to their left. Whitespace is not allowed between a
-variable name and its subscript. However, there is a corresponding
-B form of each subscript (C<@foo.[1]> and C<%bar.{'a'}>). Constant
-string subscripts may be placed in angles, so C<%bar.{'a'}> may also
-be written as C<< %bar >> or C<< %bar. >>.
+variable name and its subscript. However, there are two ways to
+stretch the construct out visually. Since a subscript is a kind
+of postfix operator, there is a corresponding B form of each
+subscript (C<@foo.[1]> and C<%bar.{'a'}>) that makes the dereference
+a little more explicit. Constant string subscripts may be placed
+in angles, so C<%bar.{'a'}> may also be written as C<< %bar >>
+or C<< %bar. >>. Additionally, you may insert extra whitespace
+using the unspace.
=item *
Re: S02 questions and comments
On Sun, Mar 30, 2008 at 04:35:56PM -, John M. Dlugosz wrote: : Meta-question 2: Does this belong on a different mailing list? I'm also including the documented file maintainer as a direct recipient. This is the right list. There is no need to cc the maintainers, since they all read this list (or if they do not, are not really the maintainers any more...) : 4: "Whitespace is not allowed between a variable name and its subscript. However, there is a corresponding dot form of each subscript" : The use of "however" looks like it is meant to imply that the dot form allows you to add space. I think this wording is leftover from the "long dot" explanation, but now is out of place. I suggest dropping the "However," from the sentence. Fixed by unpacking what I really meant by the "however". :) Larry
Re: S09 editorial fixes
On Thu, Apr 03, 2008 at 12:43:58AM +0800, Audrey Tang wrote:
> Larry Wall 提到:
>> Yes, unless we decide we need something like that for list
>> comprehensions. Maybe looping modifiers allow placeholders in what
>> would otherwise be an error...
>
> Sure. How about this:
>
> "
> Use of a placeholder parameter in statement-level blocks triggers a
> syntax error, because the parameter is not out front where it can be
> seen. However, it's not an error when prefixed by a C, or when
> followed by a statement modifier:
>
> # Syntax error: statement-level placeholder block
> { say $^x };
>
> # Not an syntax error, though $x doesn't get the argument it wants
> do { say $^x };
>
> # Not an error at all
> { say $^x } for 1..10;
> "
I was originally thinking just loop modifiers, but I suppose
{ say $^x } if foo();
also can be made to make some kind of sense, in the same way that
if foo() -> $x { say $x }
is supposed to work. And we have to do it like that anyway if
we want to say something like:
{ say $^x } if .odd for 1..10;
> I do find it interesting that, because "any block just inside a left
> parenthesis is immediately called like a bare block", we have:
>
> my $x = {1+1};# $x is a Code
> my $y = ({1+1}); # $y is 2!
>
> Is that correct?
Yes, current STD has the inside of () and [] as ,
which throws away all but the last statement. Arguably [] at least
should probably be though, and maybe () too.
my @x := [{1+1}; {2+2}]; @x is currently [4], should be [2,4]?
my @x = ({1+1}; {2+2}); same deal?
Larry
Re: muse on Compact Structs, pack/unpack
On Tue, Apr 01, 2008 at 09:27:48PM -0500, John M. Dlugosz wrote: > Having done that before, I find the Perl 6 technical docs to be in relative > disarray and imprecise. Indeed, I welcome all the help I can get on making things more precise. My own tendency is to emphasize vigor over rigor, so I welcome any balance on that score. And please don't be discouraged by any of my traditional morning grumpiness. I don't need a jet to get jet lagged. :) Larry
[svn:perl6-synopsis] r14536 - doc/trunk/design/syn
Author: audreyt
Date: Wed Apr 2 10:22:01 2008
New Revision: 14536
Modified:
doc/trunk/design/syn/S04.pod
Log:
* S04: Create a new section, "Statement-level bare blocks"
since its content doesn't really belong in the "do-once loop"
section.
* S04: Also, clarify that statement-level blocks with placeholder
variables should trigger an error, unless prefixed with "do"
or postfixed with a modifier.
Modified: doc/trunk/design/syn/S04.pod
==
--- doc/trunk/design/syn/S04.pod(original)
+++ doc/trunk/design/syn/S04.podWed Apr 2 10:22:01 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 19 Aug 2004
- Last Modified: 8 Feb 2008
+ Last Modified: 2 Apr 2008
Number: 4
- Version: 64
+ Version: 65
This document summarizes Apocalypse 4, which covers the block and
statement syntax of Perl.
@@ -533,15 +533,6 @@
useful for the do-once block, since it is offically a loop and can take
therefore loop control statements.
-Although a bare block is no longer a do-once loop, it still executes
-immediately as in Perl 5, as if it were immediately dereferenced with
-a C<.()> postfix, so within such a block C refers to the
-scope surrounding the block. If you wish to return a closure from a
-function, you must use an explicit prefix such as C or C
-or C<< -> >>. (Use of a placeholder parameter is deemed insufficiently
-explicit because it's not out front where it can be seen. You can, of
-course, use a placeholder parameter if you also use C.)
-
Another consequence of this is that any block just inside a
left parenthesis is immediately called like a bare block, so a
multidimensional list comprehension may be written using a block with
@@ -553,6 +544,32 @@
@names = ({ "$^name.$^num" } for 'a'..'zzz' X 1..100);
+=head2 Statement-level bare blocks
+
+Although a bare block occuring as a single statement is no longer
+a do-once loop, it still executes immediately as in Perl 5, as if it
+were immediately dereferenced with a C<.()> postfix, so within such a
+block C refers to the scope surrounding the block.
+
+If you wish to return a closure from a function, you must use an
+explicit prefix such as C or C or C<< -> >>.
+
+Use of a placeholder parameter in statement-level blocks triggers a
+syntax error, because the parameter is not out front where it can be
+seen. However, it's not an error when prefixed by a C, or when
+followed by a statement modifier:
+
+# Syntax error: Statement-level placeholder block
+{ say $^x };
+
+# Not an syntax error, though $x doesn't get the argument it wants
+do { say $^x };
+
+# Not an error: Equivalent to "for 1..10 -> $x { say $x }"
+{ say $^x } for 1..10;
+
+# Not an error: Equivalent to "if foo() -> $x { say $x }"
+{ say $^x } if foo();
=head2 The gather statement
Re: S09 editorial fixes
Larry Wall 提到:
> I was originally thinking just loop modifiers, but I suppose
>
> { say $^x } if foo();
>
> also can be made to make some kind of sense, in the same way that
>
> if foo() -> $x { say $x }
>
> is supposed to work.
Right. I've committed the clarification (as a new section). Thanks!
> Yes, current STD has the inside of () and [] as ,
> which throws away all but the last statement. Arguably [] at least
> should probably be though, and maybe () too.
>
> my @x := [{1+1}; {2+2}]; @x is currently [4], should be [2,4]?
> my @x = ({1+1}; {2+2}); same deal?
That's what I'd expect, yes.
Cheers,
Audrey
[svn:perl6-synopsis] r14537 - doc/trunk/design/syn
Author: larry Date: Wed Apr 2 11:02:36 2008 New Revision: 14537 Modified: doc/trunk/design/syn/S02.pod doc/trunk/design/syn/S03.pod Log: typo from Jon Lang++ clarify innards of () and [] slightly Modified: doc/trunk/design/syn/S02.pod == --- doc/trunk/design/syn/S02.pod(original) +++ doc/trunk/design/syn/S02.podWed Apr 2 11:02:36 2008 @@ -1489,7 +1489,7 @@ &foo($arg1, $arg2); -Whitespace is not allowed before the parens because it it is parsed as +Whitespace is not allowed before the parens because it is parsed as a postfix. As with any postfix, there is also a corresponding C<.()> operator, and you may use the "unspace" form to insert optional whitespace and comments between the backslash and either of the Modified: doc/trunk/design/syn/S03.pod == --- doc/trunk/design/syn/S03.pod(original) +++ doc/trunk/design/syn/S03.podWed Apr 2 11:02:36 2008 @@ -85,7 +85,7 @@ This isn't really a precedence level, but it's in here because no operator can have tighter precedence than a term. See S02 for longer descriptions of -various terms. +various terms. Here are some examples. =over @@ -137,7 +137,10 @@ [1,2,3] -Provides list context inside. +Provides list context inside. (Technically, it really provides a +"semilist" context, which is a semicolon-separated list of statements, +each of which is interpreted in list context and then concatenated +into the final list.) =item * @@ -213,11 +216,14 @@ =item * -Circumfixed subexpressions +Subexpressions circumfixed by parentheses (1+2) -Circumfixed items are treated like a term on the outside. +Parentheses are parsed on the inside as a semicolon-separated list +of statements, which (unlike the statements in a block) returns the results +of all the statements concatenated together as a C of C. +How that is subsequently treated depends on its eventual binding. =item *
Re: S09 editorial fixes
On Wed, Apr 02, 2008 at 10:03:57AM -0700, Larry Wall wrote:
> Yes, current STD has the inside of () and [] as ,
> which throws away all but the last statement. Arguably [] at least
> should probably be though, and maybe () too.
>
> my @x := [{1+1}; {2+2}]; @x is currently [4], should be [2,4]?
> my @x = ({1+1}; {2+2}); same deal?
So if the semicolon is replaced with a comma, like this,
my @x := [{1+1}, {2+2}];
the {} acts as a hash constructor, and @x is [{2 => undef}, {4 => undef}] ?
And similarly for
my @x := ({1+1}, {2+2});
?
If so, does that mean that [{1 + 1}] and [; {1 + 1}] differ?
And [; {1 + 1}] and [{1 + 1}; ] are identical?
Nicholas Clark
[svn:perl6-synopsis] r14538 - doc/trunk/design/syn
Author: audreyt
Date: Wed Apr 2 12:04:08 2008
New Revision: 14538
Modified:
doc/trunk/design/syn/S03.pod
Log:
* S03/"Hash composer":
Update the definition to agree with S04/"hash composer", allowing
empty hashes as well as lists beginning with hashes.
Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podWed Apr 2 12:04:08 2008
@@ -12,9 +12,9 @@
Maintainer: Larry Wall <[EMAIL PROTECTED]>
Date: 8 Mar 2004
- Last Modified: 31 Mar 2008
+ Last Modified: 2 Apr 2008
Number: 3
- Version: 134
+ Version: 135
=head1 Overview
@@ -146,10 +146,11 @@
Hash composer
+{ }
{ a => 42 }
-Inside must be a list of pairs, otherwise you must use C
-or C<%()> instead.
+Inside must be either empty, or a single list starting with a pair or a hash,
+otherwise you must use C or C<%()> instead.
=item *
Re: S09 editorial fixes
Nicholas Clark 提到:
So if the semicolon is replaced with a comma, like this,
my @x := [{1+1}, {2+2}];
the {} acts as a hash constructor, and @x is [{2 => undef}, {4 => undef}] ?
No, {} acts as a closure constructor, and @x contains two closures that
returns 2 and 4 respectively when called:
@x[0](); # 2
@x[1](); # 4
Basically, {} is only a hash constructor if the inside is either empty,
or contains only a list starting with a pair or a hash:
$hash = { };
$hash = { %stuff };
$hash = { "a" => 1 };
$hash = { "a" => 1, $b, $c, %stuff, @nonsense };
$code = { ; };
$code = { @stuff };
$code = { "a", 1 };
$code = { "a" => 1, $b, $c ==> print };
The examples above are from L.
Cheers,
Audrey
Re: S09 editorial fixes
Thom Boyer 提到:
Audrey Tang wrote:
$code = { "a" => 1, $b, $c ==> print };
The examples above are from L.
According to those rules, that last assignment to $code seems to be a
hash, not code. Or does the C<< ==> >> mean that the contents aren't a
list?
Correct, because "==>" binds looser than "," (i.e., Terminator is looser
than Comma), so the toplevel in that block is not a list, but a feed.
Cheers,
Audrey
Re: muse on Compact Structs, pack/unpack
Larry Wall larry-at-wall.org |Perl 6| wrote: On Tue, Apr 01, 2008 at 09:27:48PM -0500, John M. Dlugosz wrote: Having done that before, I find the Perl 6 technical docs to be in relative disarray and imprecise. Indeed, I welcome all the help I can get on making things more precise. My own tendency is to emphasize vigor over rigor, so I welcome any balance on that score. And please don't be discouraged by any of my traditional morning grumpiness. I don't need a jet to get jet lagged. :) Larry During ANSI/ISO standardization, they basically took every phrase and made it more and more exact. It went from understandable to leagaleze over a period of years, with sentences growing more and more detail. I could still follow it having come to it gradually. Hypertext could remedy that. --John
Re: S09 editorial fixes
Regarding the text just before where you rewrote,
then the compiler adds defaults for you, something like:
-> $x = @foo.shape[0].range,
$y = @foo.shape[1].range { @foo[$x;$y] }
where each such range is autoiterated for you.
That doesn't really work. If you used these defaults instead of
autoindex, with a real example like
-> $i, $j, $k, $l { @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l] }();
the same Range object is used in all occurances of the variable.
As an aside, the use of a Range value in a subscript that is written as
a simple scalar variable will make a mess of the compiler's determining
that it was supposed to be a single value not a slice! I think it would
not turn into a list but would fail as not being a number. In any case,
if * worked between lists as returned by the slices, it would not do
anything like the implied iteration would do, and it would not be
stuffed back into the @c in any semblance of an answer.
So, the example of @foo[$x;$y] is pointless, and saying that it uses a
Range as the default does not illustrate what it really means.
So, (1) use an example that has the salent features of a dependant and a
defining occurance of the index; and (2) show (near) equivilent code
that is correct.
My stab at it: (please check)
"
-> $x, $y { @foo[$x;$y] = f($x)[EMAIL PROTECTED] }
becomes
for @foo.shape[0].range Z @foo.shape[1].range-> $x, $y { @foo[$x;$y] =
f($x)[EMAIL PROTECTED] }
where the iteration limits on the variables are determined by their use
in subscripts. For the exact rules of which subscript usage is deemed to
be the defining occurance, see the PDL docs.
"
I have more thoughts on this feature, but I'll save it for later. I
think it will jell more after I digest some of Larry's posts today.
--John
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote:
> John M. Dlugosz 提到:
>
>
>> = on Parallelized parameters and autothreading
>>
>> use autoindex;
>> do { @c[$^i, $^j, $^k, $^l] = @a[$^i, $^j] * @b[$^k, $^l] };
>>
>> Shouldn't those be semicolons? Ditto for subsequent examples.
>> Also, what does the "do" do? I think it is only meaningful if there was
>> something using this block's return value. I suspect it is a relic of p5
>> notation.
>>
>
> No, something more subtle is going on -- the "do STATEMENT" notation
> sees a stand-alone block in statement position, so it's automatically
> called with no arguments.
>
> Here is a rewrite of that section starting from line 1044 onward.
> Sanity-check before I check it in?
>
> "
> In the abstract (and often in the concrete), this puts an implicit
> loop around the block of the closure that visits all the possible
> subscript values for that dimension (unless the parameter is actually
> supplied to the closure, in which case the supplied value is used as
> the slice subscript instead).
>
> This implicit loop is assumed to be parallelizable.
> So to write a typical tensor multiplication:
>
> Cijkl = Aij * Bkl
>
> you can simply call a closure with no arguments, allowing the C
> pragma to fill in the defaults:
>
> use autoindex;
> -> $i, $j, $k, $l { @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l] }();
>
> or you can use the C syntax to execute a stand-alone closure,
> which also implicit loops:
>
> use autoindex;
> do -> $i, $j, $k, $l {
> @c[$i; $j; $k; $l] = @a[$i; $j] * @b[$k; $l]
> }
>
> or even use placeholder variables instead of a parameter list:
>
> use autoindex;
> do { @c[$^i; $^j; $^k; $^l] = @a[$^i; $^j] * @b[$^k; $^l] };
>
> That's almost pretty.
> "
>
>
>
Re: S09 editorial fixes
Audrey Tang audreyt-at-audreyt.org |Perl 6| wrote: > > I guess the wording in the last parenthesized parens is insufficiently > explicit, and maybe we should change it to say that it's really a syntax > error to use placeholder blocks in statement positions. Sounds reasonable? > > Cheers, > Audrey > Looks like it's already been processed, but I agree. If you have a block that is not executed immediatly and is not being assigned to anything either, that is always a compile-time warning. If your variables are typed and you get a Code where you expected a result, that would be a compile-time error since it knows the types never match. And finally, the case of making a block "not bare" by using placeholders, but not be used in a situation where they could be bound to anything and then called (including the subsequent examples of suffix loop statement modifiers) should be an error. So saying it is wrong in statement position is not accurate, since there could be loop suffixes. --John
Re: muse on Compact Structs, pack/unpack
On Wed, Apr 02, 2008 at 07:03:46PM -0500, John M. Dlugosz wrote: > During ANSI/ISO standardization, they basically took every phrase and made > it more and more exact. It went from understandable to leagaleze over a > period of years, with sentences growing more and more detail. I could > still follow it having come to it gradually. > > Hypertext could remedy that. "All problems in computer science can be solved by another level of indirection." -- Butler Lampson "...except the problem of too many levels of indirection." -- Larry's Amendment to Lampson's Law But yes, it might be about time for hypertexting it. All but S03 have never really undergone a major reorg, and most of them could use it. Maybe it's time to set up Twiki on my home machine... Larry
Re: Question on your last change to S02
Larry Wall larry-at-wall.org |Perl 6| wrote: Now, you'll ask how *-2 works. If you do math on a Whatever object, it just remembers that offset until the Whatever is given a meaning, which, in this case, is delayed until the subscripting operator decides what the size of the next dimension is. At a lower level than the subscript it probably ends up being some kind of a fallback multi that binds to a Whatever type for that dimension, as the subscripting operator processes through each dimension in its @@ array. Or maybe it's just a case in a switch. In any case, the subscriptor knows the next "top" dimension, so it can know the size at that point. I see. The *-2 isn't resolved to a number right away, but evaluates to a "whatever-2" object, that is passed. The subscripting implementation knows what is going on when it gets to that. That means that ordinary uses will not require knowledge about the dimensions and context, as it is handled all inside the subscripting code. But constructs that generate loops around that expression will have to know. This certainly includes the autoindexing thing being discussed in another thread. But I'm also thinking of junctions. Junctions thread through the subscript, it is writ. A junction, like a range, can use * for an endpoint, can it not? Writing @foo[$x;2..*;$y] >>*<< blah blah will serve up the slice first, using the mechanism described above. But the similar $n=all(2..*); @foo[$x;$n;$y] * blah blah is described as creating a loop around the * operator. I guess it would convert to the first one and see what the subscripter gave back? Is that still possible if multiple junctions are present? --John
Re: Question on your last change to S02
Larry Wall larry-at-wall.org |Perl 6| wrote: At compile time the subscript parser really only knows how many dimensions are referred to by how many semicolons there are. A subscript that is explicitly cast to @@ is known to be multidimensional, and interpolates the returned List of Capture into the outer List of Capture, and the compiler can make no compile-time assumptions about how far down the dimension list any subsequent dimensional sublists will end up. What I still want to know is: When does .[] provide a single item, rather than a list (a list that might contain only one item)? $x = @array[$n]; # I expect $x holds the single result, not a list of one item! $x = @array[foo()]; # what about now? --John
postfix and postcircumfix
In "Question on your last change to S02", Larry Wall wrote: > (By the way, you'll note the utility of being able to talk about a > postfix by saying .[], which is one of the reasons we allow the optional > dot there. :) Can I take this as an indication that the rules for postcircumfix operators are an extension of the rules for postfix operators? -- Jonathan "Dataweaver" Lang
