S09 editorial fixes

I just finished another pass on S09<v24>, and in this posting I note editori
al 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 post
s.

= 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 mentione
d 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<[url]http://en.wikipedia.org/wiki/Perl_Data_Language[/u
rl]> ) 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 supp
ort in the core language, a
nd 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 some
thing 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 som
ething using this block's return value.  I suspect it is a relic of p5 notat
ion.

= on Autovivification

"Note that assignment implicitly binds a copy..."
Does assignment do binding?  I thought it would change the value in the exis
ting container using its assignment function, not create a new container!  I
s 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

John M. Dlugosz =B4=A3=A8=EC:

> =3D on Parallelized parameters and autothreading
>=20
>     use autoindex;
>     do { @c[$^i, $^j, $^k, $^l] =3D @a[$^i, $^j] * @b[$^k, $^l] };
>=20
> Shouldn't those be semicolons?  Ditto for subsequent examples.
> Also, what does the "do" do?  I think it is only meaningful if there wa=
s 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 =3D Aij * Bkl

you can simply call a closure with no arguments, allowing the C<autoindex=
>
pragma to fill in the defaults:

use autoindex;
-> $i, $j, $k, $l { @c[$i; $j; $k; $l] =3D @a[$i; $j] * @b[$k; $l] }(=
);

or you can use the C<do STATEMENT> syntax to execute a stand-alone closur=
e,
which also implicit loops:

use autoindex;
do -> $i, $j, $k, $l {
@c[$i; $j; $k; $l] =3D @a[$i; $j] * @b[$k; $l]
}

or even use placeholder variables instead of a parameter list:

use autoindex;
do { @c[$^i; $^j; $^k; $^l] =3D @a[$^i; $^j] * @b[$^k; $^l] };

That's almost pretty.
"

Audrey Tang =B4=A3=A8=EC:
> John M. Dlugosz =B4=A3=A8=EC:
>=20 
as something using this block's return value.  I suspect it is a relic of=
p5 notation.
>=20
> 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<do BLOCK> syntax (see L<S04/"The do-once loop"> ) to
call that closure, which also implicit iterates:
"

Cheers,
Audrey

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

John M. Dlugosz =B4=A3=A8=EC:

> 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.=

>=20
> foo;
> bar;
> { my $temp=3D 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<CALLER::> 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<return> or C<sub>
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<return>.)
"

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 reasonabl=
e?

Cheers,
Audrey

John M. Dlugosz =B4=A3=A8=EC:
> I just finished another pass on S09<v24>, and in this posting I note ed=
itorial issues with the file that can easily be corrected.  This is as op=
posed to subjects for deep discussion, which I'll save for later and indi=
vidual posts.
>=20
> =3D on Mixing subscripts
> "Within a C<.[]> indexing operation..."
> Why the dot?  The examples don't use a dot, and this makes it sound lik=
e the dot is involved and that is confusing.  I see that C<.{}> was also =
mentioned earlier. =20

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.

> =3D on The semicolon operator
>=20
> "Another thing that's not going to fly easily is simply dropping out te=
rms...." to the end of the section.
>=20
> 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

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

Larry Wall =E6=8F=90=E5=88=B0:
> 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<do>, 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=20
parenthesis is immediately called like a bare block", we have:

my $x =3D {1+1};	# $x is a Code
my $y =3D ({1+1});	# $y is 2!

Is that correct?

Cheers,
Audrey

On Thu, Apr 03, 2008 at 12:43:58AM +0800, Audrey Tang wrote:
> Larry Wall 提到: 
>
> 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<do>, 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 <statementlist>,
which throws away all but the last statement.  Arguably [] at least
should probably be <semilist> 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

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 <statementlist>,
> which throws away all but the last statement.  Arguably [] at least
> should probably be <semilist> 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