Re: state statements versus state expressions

2012-09-20 Thread Larry Wall
On Tue, Sep 11, 2012 at 10:25:03PM +0100, Nicholas Clark wrote:
: On Tue, Sep 11, 2012 at 11:11:11PM +0200, Carl Mäsak wrote:
: > Nicholas (>):
: > > Where in the synopses (or other documents) does it explain why these two
: > > are different?
: > >
: > > $ ./perl6 -e 'sub foo {state @a = (3, 4); say ++@a[0];}; foo; foo;'
: > > 4
: > > 5
: > > $ ./perl6 -e 'sub foo {(state @a) = (3, 4); say ++@a[0];}; foo; foo;'
: > > 4
: > > 4
: > 
: > S03:4912. "Each declarator can take an initializer following an equals
: > sign (which should not be confused with a normal assignment, because
: > the timing of the initialization depends on the natural lifetime of
: > the container, which in turn depends on which declarator you use)."
: 
: Thanks, but if I read that I wouldn't make this jump from it:
: 
: > In other words, the parens turn the special equals sign into normal
: > assignment again.
: 
: (which I'm fine with, as a reason. Although my mental model of it was
: "When it's a statement, it's special, with an implied phaser block.
: If it's part of an expression, however trivial, it can't be special")

There is no sense in which a declarator is a statement.  (Not even in
Perl 5.)  A declarator is simply a term.  The difference from Perl 5
is that in Perl 6, declarators are kinda like macros that can look for
more arguments, and the initializer argument happens to be labelled
with an '=' instead of something like :init(42).  The extra parens just
do term isolation in this case.

: So I guess my next question is "where is normal assignment explained?"
: Specifically, the part that would explain that you can put C or C
: or similar within the list on the left of the C<=>.

Er, why would normal assignment want to explain something that isn't normal?

Anyway, normal assignment is also explained in S03, albeit somewhat diffusely.

Larry


Re: state statements versus state expressions

2012-09-11 Thread Nicholas Clark
On Tue, Sep 11, 2012 at 11:11:11PM +0200, Carl Mäsak wrote:
> Nicholas (>):
> > Where in the synopses (or other documents) does it explain why these two
> > are different?
> >
> > $ ./perl6 -e 'sub foo {state @a = (3, 4); say ++@a[0];}; foo; foo;'
> > 4
> > 5
> > $ ./perl6 -e 'sub foo {(state @a) = (3, 4); say ++@a[0];}; foo; foo;'
> > 4
> > 4
> 
> S03:4912. "Each declarator can take an initializer following an equals
> sign (which should not be confused with a normal assignment, because
> the timing of the initialization depends on the natural lifetime of
> the container, which in turn depends on which declarator you use)."

Thanks, but if I read that I wouldn't make this jump from it:

> In other words, the parens turn the special equals sign into normal
> assignment again.

(which I'm fine with, as a reason. Although my mental model of it was
"When it's a statement, it's special, with an implied phaser block.
If it's part of an expression, however trivial, it can't be special")

So I guess my next question is "where is normal assignment explained?"
Specifically, the part that would explain that you can put C or C
or similar within the list on the left of the C<=>.

"normal assignment" seems to be term favoured by other parts of the synopses
to describe what they are *not*. But doesn't seem to be easy to find in
itself - ie what it *is* :-)

Nicholas Clark


Re: state statements versus state expressions

2012-09-11 Thread Carl Mäsak
Nicholas (>):
> Where in the synopses (or other documents) does it explain why these two
> are different?
>
> $ ./perl6 -e 'sub foo {state @a = (3, 4); say ++@a[0];}; foo; foo;'
> 4
> 5
> $ ./perl6 -e 'sub foo {(state @a) = (3, 4); say ++@a[0];}; foo; foo;'
> 4
> 4

S03:4912. "Each declarator can take an initializer following an equals
sign (which should not be confused with a normal assignment, because
the timing of the initialization depends on the natural lifetime of
the container, which in turn depends on which declarator you use)."

In other words, the parens turn the special equals sign into normal
assignment again.

// Carl