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 <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?

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

Nicholas Clark =E6=8F=90=E5=88=B0:
> So if the semicolon is replaced with a comma, like this,
>=20
>     my @x :=3D [{1+1}, {2+2}];
>=20
> the {} acts as a hash constructor, and @x is [{2 =3D> undef}, {4 =3D> u=
ndef}] ?

No, {} acts as a closure constructor, and @x contains two closures that=20
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,=20
or contains only a list starting with a pair or a hash:

$hash =3D { };
$hash =3D { %stuff };
$hash =3D { "a" =3D> 1 };
$hash =3D { "a" =3D> 1, $b, $c, %stuff, @nonsense };

$code =3D { ; };
$code =3D { @stuff };
$code =3D { "a", 1 };
$code =3D { "a" =3D> 1, $b, $c =3D=3D> print };

The examples above are from L<S04/"Statement parsing">.

Cheers,
Audrey

Thom Boyer =E6=8F=90=E5=88=B0:
> Audrey Tang wrote: 
>=20
> According to those rules, that last assignment to $code seems to be a=20
> hash, not code. Or does the C<< =3D=3D> >> mean that the contents aren'=
t a=20
> list?

Correct, because "=3D=3D>" binds looser than "," (i.e., Terminator is loo=
ser=20
than Comma), so the toplevel in that block is not a list, but a feed.

Cheers,
Audrey

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

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)+@c[$y] }

becomes

for @foo.shape[0].range Z @foo.shape[1].range-> $x, $y { @foo[$x;$y] =
f($x)+@c[y] }

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 ´£¨ì:
>
> 
>
> 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<autoindex>
> 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<do STATEMENT> 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.
> "
>
>
>