On Wed, Sep 06, 2000 at 12:05:21PM +1100, Damian Conway wrote:
>> This bothers me. Name an operation in perl that, when applied to
>> a single element of an aggregate, affects all other elements of
>> the aggregate (especially future, as-yet-unborn elements).
>
> There are remarkably
2000-08-28-18:47:06 Tom Christiansen:
> It strikes me as a bit reminiscent of (one reason) why Larry
> didn't make a+b work on strings, since then while with numbers,
> a+b and b+a would be the same, with strings they would not be, and
> we have these rather deeply held convictions about such matt
>On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>>> exists (sometimes causes autovivification, which affects C)
>>
>>That's not technically accurate--exists never causes autovivification.
> print exists $hash{foo}{bar}{baz};
> use Data::Dumper;
> print Dumpe
> > print keys %hash, "\n";
> > exists $hash{key}{subkey};
> > print keys %hash, "\n";
>
> >Or did that get fixed when I wasn't looking?
>
> No, the -> operator has not been changed to do lazy evaluation.
That's not required. All that is necessary is for C nodes
in the o
> Why can't we just apply the same warnings on hashes as we do on
> variables in Perl? Maybe a new lexical pragma:
>
> no autoviv; # any autovivification carps (not just
> # hashes)
>
> no autoviv 'HASH'; # no
>That's not required. All that is necessary is for C nodes
>in the op tree to propagate a special non-autovivifying context to
>subordinate nodes.
That seems reasonable--except that I don't believe exists() merits
any special treatment.
--tom
>That seems reasonable--except that I don't believe exists() merits
>any special treatment.
More specifically, I think all non-lvalue context use of -> should be
non-autoviv, whether exists or anything else.
--tom
> >That seems reasonable--except that I don't believe exists() merits
> >any special treatment.
>
> More specifically, I think all non-lvalue context use of -> should be
> non-autoviv, whether exists or anything else.
I agree entirely.
In fact, I shall extend RFC 128 to allow
>I agree entirely.
>In fact, I shall extend RFC 128 to allow subroutine parameter to specify
>that they are non-autovivifying.
I'm not sure why it matters to the subroutine. We've already got the hack
so that
fn( $a[$i] )
or
fn( $h{$k} )
will only autoviv those puppies if you muddle
> >In fact, I shall extend RFC 128 to allow subroutine parameter to specify
> >that they are non-autovivifying.
>
> I'm not sure why it matters to the subroutine. We've already got
> the hack so that
>
> fn( $a[$i] )
> or
> fn( $h{$k} )
>
> will onl
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>> exists (sometimes causes autovivification, which affects C)
>
>That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper \
11 matches
Mail list logo
