Mailing List Archive: Perl: porters

Perl 6 is not a menu (was Re: Named prototypes (again))

1 2

View All

Index | Next | Previous | View Threaded

xdg at xdg

Sep 10, 2012, 10:49 AM

Post #26 of 33 (55 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

On Mon, Sep 10, 2012 at 1:41 PM, Nicholas Clark <nick [at] ccl4> wrote:
> [snip]
> 5) (state @a) = (1, 2);
> # needs to be equivalent to
> state @a; @a = (1, 2);
> [snip]
> a) it would be wrong to add (5) as something that is accepted by the parser,
> but compiled to something that Larry says is wrong

I understand what you're saying. I'm questioning "...Larry says is
wrong". Or rather -- I'm questioning the context of Larry's view of
wrong. Starting from a blank slate (Perl 6), then sure, it should
work as Larry says. But we're not. And I think the utility of 4
vastly outweights the utility of 5, since 5 can be accomplished with
nearly the same effect using "my" instead of "state". (Nearly in that
I think state might avoid some SV churn.)

Perl 6 is not a menu, but nor should every design decision made for
Perl 6 be the gold standard for related design decisions in Perl 5.

David

--
David Golden <xdg [at] xdg>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

doy at tozt

Sep 10, 2012, 10:52 AM

Post #27 of 33 (56 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

On Mon, Sep 10, 2012 at 01:49:42PM -0400, David Golden wrote:
> On Mon, Sep 10, 2012 at 1:41 PM, Nicholas Clark <nick [at] ccl4> wrote:
> > [snip]
> > 5) (state @a) = (1, 2);
> > # needs to be equivalent to
> > state @a; @a = (1, 2);
> > [snip]
> > a) it would be wrong to add (5) as something that is accepted by the parser,
> > but compiled to something that Larry says is wrong
>
> I understand what you're saying. I'm questioning "...Larry says is
> wrong". Or rather -- I'm questioning the context of Larry's view of
> wrong. Starting from a blank slate (Perl 6), then sure, it should
> work as Larry says. But we're not. And I think the utility of 4
> vastly outweights the utility of 5, since 5 can be accomplished with
> nearly the same effect using "my" instead of "state". (Nearly in that
> I think state might avoid some SV churn.)
>
> Perl 6 is not a menu, but nor should every design decision made for
> Perl 6 be the gold standard for related design decisions in Perl 5.

For what it's worth, regardless of what Perl 6 does, I would expect case
5 to work as Nicholas describes, just based on how other similar
features in Perl 5 work.

-doy

abigail at abigail

Sep 10, 2012, 11:13 AM

Post #28 of 33 (55 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

On Mon, Sep 10, 2012 at 12:52:33PM -0500, Jesse Luehrs wrote:
> On Mon, Sep 10, 2012 at 01:49:42PM -0400, David Golden wrote:
> > On Mon, Sep 10, 2012 at 1:41 PM, Nicholas Clark <nick [at] ccl4> wrote:
> > > [snip]
> > > 5) (state @a) = (1, 2);
> > > # needs to be equivalent to
> > > state @a; @a = (1, 2);
> > > [snip]
> > > a) it would be wrong to add (5) as something that is accepted by the parser,
> > > but compiled to something that Larry says is wrong
> >
> > I understand what you're saying. I'm questioning "...Larry says is
> > wrong". Or rather -- I'm questioning the context of Larry's view of
> > wrong. Starting from a blank slate (Perl 6), then sure, it should
> > work as Larry says. But we're not. And I think the utility of 4
> > vastly outweights the utility of 5, since 5 can be accomplished with
> > nearly the same effect using "my" instead of "state". (Nearly in that
> > I think state might avoid some SV churn.)
> >
> > Perl 6 is not a menu, but nor should every design decision made for
> > Perl 6 be the gold standard for related design decisions in Perl 5.

Yeah, that was my feeling as well. Unless Larry specifically said perl *5*
should behave in the same was as perl 6, I don't think there's anything
wrong with implementing it more in a natural perl 5 way.

> For what it's worth, regardless of what Perl 6 does, I would expect case
> 5 to work as Nicholas describes, just based on how other similar
> features in Perl 5 work.

I would expect not to be a difference between:

(state @a) = (1, 2);

and

state @a = (1, 2);

You mention you base your opinion on "how other similar features in Perl 5
work". Can you be more specific? Nothing immediately springs into my mind,
but Perl is a big language, and there may be something I'm missing.

For

(state @a) = (1, 2)

to mean

state @a; @a = (1, 2);

is something I find surprising. And does it actually add any value? Is there,
for the user (the Perl programmer) any advantage to ever write:

(state @a) = (1, 2)

with the described meaning? I mean, for all intends and purposes, it acts
the same as

my @a = (1, 2)

doesn't it?

Regards,

Abigail

doy at tozt

Sep 10, 2012, 11:33 AM

Post #29 of 33 (55 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

On Mon, Sep 10, 2012 at 08:13:12PM +0200, Abigail wrote:
> On Mon, Sep 10, 2012 at 12:52:33PM -0500, Jesse Luehrs wrote:
> > On Mon, Sep 10, 2012 at 01:49:42PM -0400, David Golden wrote:
> > > On Mon, Sep 10, 2012 at 1:41 PM, Nicholas Clark <nick [at] ccl4> wrote:
> > > > [snip]
> > > > 5) (state @a) = (1, 2);
> > > > # needs to be equivalent to
> > > > state @a; @a = (1, 2);
> > > > [snip]
> > > > a) it would be wrong to add (5) as something that is accepted by the parser,
> > > > but compiled to something that Larry says is wrong
> > >
> > > I understand what you're saying. I'm questioning "...Larry says is
> > > wrong". Or rather -- I'm questioning the context of Larry's view of
> > > wrong. Starting from a blank slate (Perl 6), then sure, it should
> > > work as Larry says. But we're not. And I think the utility of 4
> > > vastly outweights the utility of 5, since 5 can be accomplished with
> > > nearly the same effect using "my" instead of "state". (Nearly in that
> > > I think state might avoid some SV churn.)
> > >
> > > Perl 6 is not a menu, but nor should every design decision made for
> > > Perl 6 be the gold standard for related design decisions in Perl 5.
>
>
> Yeah, that was my feeling as well. Unless Larry specifically said perl *5*
> should behave in the same was as perl 6, I don't think there's anything
> wrong with implementing it more in a natural perl 5 way.
>
>
> > For what it's worth, regardless of what Perl 6 does, I would expect case
> > 5 to work as Nicholas describes, just based on how other similar
> > features in Perl 5 work.
>
> I would expect not to be a difference between:
>
> (state @a) = (1, 2);
>
> and
>
> state @a = (1, 2);
>
>
> You mention you base your opinion on "how other similar features in Perl 5
> work". Can you be more specific? Nothing immediately springs into my mind,
> but Perl is a big language, and there may be something I'm missing.
>
> For
>
> (state @a) = (1, 2)
>
> to mean
>
> state @a; @a = (1, 2);
>
> is something I find surprising. And does it actually add any value? Is there,
> for the user (the Perl programmer) any advantage to ever write:
>
> (state @a) = (1, 2)
>
> with the described meaning? I mean, for all intends and purposes, it acts
> the same as
>
> my @a = (1, 2)

What would

(my $foo, state $bar) = @BAZ;

do?

Variable declaration and assignment are separate things, and everywhere
else in the language, you can (scoping issues aside) replace a 'my $foo'
wihtin an expression with 'my $foo' followed by the expression as-is,
with the 'my' removed, as in "open my $foo, ..." vs
"my $foo; open $foo, ...".

A list assignment like "(state @bar) = (...)" is just a normal
expression, and should be equivalent to what happens when you split up
the declaration from the assignment, as in "state @bar; (@bar) = (...)".

-doy

nick at ccl4

Sep 10, 2012, 11:53 AM

Post #30 of 33 (54 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

On Mon, Sep 10, 2012 at 08:13:12PM +0200, Abigail wrote:

> I would expect not to be a difference between:
>
> (state @a) = (1, 2);
>
> and
>
> state @a = (1, 2);

Me neither, at face value. But then, what are the "only once" semantics of

(state @a) = func();
(state $a, state $b) = func();
(state $a, undef, state $b) = func();
(state $a, my $b, state $c) = func();

where func() has side effects?

Which have implicit START blocks added around func() so that it's called
only once? Clearly the last one can't, as my $b needs assigning to every
time. So where is the line, below which a START block isn't implied?
And how does one describe it clearly?

I didn't have a good answer to this, certainly not enough to be confident
that I knew better than Larry.

Nicholas Clark

Eirik-Berg.Hanssen at allverden

Sep 10, 2012, 11:58 AM

Post #31 of 33 (55 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

On Mon, Sep 10, 2012 at 8:13 PM, Abigail <abigail [at] abigail> wrote:

> Is there,
> for the user (the Perl programmer) any advantage to ever write:
>
> (state @a) = (1, 2)
>
> with the described meaning? I mean, for all intends and purposes, it acts
> the same as
>
> my @a = (1, 2)
>
> doesn't it?
>

... feel free to call me crazy ...

use 5.014;
use warnings;

for my $x (0..9) {
$x % 3 and goto WHOA;
state @a; @a = (1, 2);
my @b = (1, 2);
WHOA:
say "@a\t@b";
pop @a; pop @b;
}

__END__
1 2 1 2
1

1 2 1 2
1

1 2 1 2
1

1 2 1 2

Eirik

abigail at abigail

Sep 10, 2012, 3:20 PM

Post #32 of 33 (55 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

On Mon, Sep 10, 2012 at 07:53:38PM +0100, Nicholas Clark wrote:
> On Mon, Sep 10, 2012 at 08:13:12PM +0200, Abigail wrote:
>
> > I would expect not to be a difference between:
> >
> > (state @a) = (1, 2);
> >
> > and
> >
> > state @a = (1, 2);
>
> Me neither, at face value. But then, what are the "only once" semantics of
>
> (state @a) = func();
> (state $a, state $b) = func();
> (state $a, undef, state $b) = func();
> (state $a, my $b, state $c) = func();
>
> where func() has side effects?
>
> Which have implicit START blocks added around func() so that it's called
> only once? Clearly the last one can't, as my $b needs assigning to every
> time. So where is the line, below which a START block isn't implied?
> And how does one describe it clearly?

I don't know either. But a solution could be to disallow mixing state and
non-state on the LHS (until a good use can be found). Allowing

state @a = LIST;
(state @a) = LIST;
(state $a, state $b, ...) = LIST;

but disallowing more complex things like:

(state $a, undef, state $b) = func();
(state $a, my $b, state $c) = func();

is a way forward. Even if only

state @a = LIST;

is allowed, it's still progress for the programmers point of view. It
gives the programmer more functionality, without p5p having to commit
on a meaning of the more complex examples.

I'm not going to pretent I know how to actually implement this, and
maybe it's just a rubbish suggestion -- in which case, just ignore this.

Abigail

perl-diddler at tlinx

Sep 10, 2012, 8:33 PM

Post #33 of 33 (57 views)
Permalink

Re: Perl 6 is not a menu (was Re: Named prototypes (again)) [In reply to]

Nicholas Clark wrote:
>
> This is the subtilty, and sorry if I wasn't clear.
>
I appreciate the explanation...

If I can add to what you said below.. and stretch some ideas a bit...

> state @a = (1, 2);
>
> *is* equivalent to this:
>
> state @a;
> START {
> @a = (1, 2);
> }
>
----
Makes sense -- state a@ should cause the assignment to be done at start
time.
> whereas this:
>
> (state @a) = (1, 2);
>
> is equivalent to this:
>
> state @a;
> @a = (1, 2);
>
---
The way I see it, since @a is a list variable, and you are putting it
inside of a list-grouping operator, that would take the items in the
parens ($b, $a[0], $a[2]) and make CREATE a new list out of them in order
that they can receive the assignment. After the list has been created, the
'state' attribute has been lost, as the list isn't a "state" list...

Now I know the way I am describing it is probably short-cutted and
optimized
so there is no intervening created list, BUT, maybe if you want to
address that
issue you need to look at undoing that optimization step when state is
involved.

I.e. (list), creates a list for assignment to or assignment from.
It's in
the creation of that list, that the 'state' attribute should be dropped,
(or not dropped when it is not in a list.

I'm just guessing that the optimization for assigning to a list has
been done so long ago, that it's actions are now not consciously
recognized as the optimization that they are-- an optimization that
needs to be toggled when state is involved...

But this is a guess on my part given your explanation...?

Dunno if it helps any or not.

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads