develooper Front page | perl.perl5.porters | Postings from April 2018

Re: [perl #133109] push on scalar forbidden: why?

Thread Previous | Thread Next
From:
L A Walsh
Date:
April 14, 2018 02:31
Subject:
Re: [perl #133109] push on scalar forbidden: why?
Message ID:
5AD167DD.2020304@tlinx.org
Philip R Brenan via RT wrote:
> The initial experimental form was a good idea but too broad because of the
> interpretation of:
>
> for($a) {...}
>   
----
    ??
    In an earlier writeup of this, I deleted but should have left
a key phrase:

If there is no way to interpret the expression without an error
being generated, (a '@' is expected), then allow it to be processed
as a reference to an array.

However, the above is legal perl code even if '$a' is
"undef", as it should be processed as "for(undef){...}".

Since this is legal:

    for ([1,2,3],[4,5,6]) {...}  

(with loop run twice: _=[1,2,3], then _=[4,5,6]).

then this must be treated the same way (and is):

    for ([1,2,3]) {...}
(_=[1,2,3]).  There can be no treatment of a ref as an
array or hash in that context, because the ref itself is a legal
value.

    Are you saying there is some situation where somehow
that for would be treated as:
for(@$a){...}?

If so, I don't see it.  I.e. I don't see how there would be
confusion.  I.e. in a situation where it is value
to treat the value as a scalar OR an array, then the
scalar would take precedence.



> But when it was removed the removal was perhaps too broad as well and
> perhaps should not have been removed from pop, push, shift, unshift where
> it seems plausible that an extra @ can be safely added. I thought that
> perhaps Linda's scheme would fail on:
>
> my $a;
> for(keys $a) {...}
>   

If '$a' is a ref to a hash:
my $a={one=>1,two=>2};
for (keys $a) {...}, then I don't see confusion, as keys is
an operator (not a bareword), that requires a hash, right?

In that case, treating it as "%$a" would seem the only valid
interpretation.
> but in this case the point is moot so the scheme survives.  And in cases
> like:
>
> my %a = (0=>undef);
> push @{$a{0}}, 1;
> say STDERR dump(%a);
>
> it would make code much more readable.
>
> If Linda's scheme can be shown to be safe and unambiguous on all cases of
> pop, push, shift, unshift then I would like to see this capability returned
> to Perl because it is more concise.
>   

What other cases was it removed from?

I don't see a problem allowing it anywhere where:

1) it would be an error to NOT dereference the ref,
  and
2) where there is no language ambiguity.

I'm sure this was thoroughly 'hashed' out at the time, so
maybe there are cases I'm not thinking of where I could
be enlightened?  That said, though, I feel there _can't_
be any such cases -- because of the above preconditions.

If there was ambiguity before, and it was allowed,
how was it that it was not flagged as an error?

And if the code was already "legal", then dereferencing
shouldn't be considered. (i.e. "for ($a) {...}" ).

So what am I missing?
Thanks!
Linda

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About