On Sat, 09 Sep 2017 19:53:53 -0700, tomentiru...@gmail.com wrote:
> > my @h is default([])
> []
> > @h[0].push: 3
> [3]
> > @h
> []
> > @h[0]
> [3]
>
> > my %h is default({})
> {}
> > %h = 3
> 3
> > %h
> {}
> > %h
> {b => 3}
>
> The array/hash variable's default is an empty array/hash literal. If
On Sat, 09 Sep 2017 19:53:53 -0700, tomentiru...@gmail.com wrote:
> > my @h is default([])
> []
> > @h[0].push: 3
> [3]
> > @h
> []
> > @h[0]
> [3]
>
> > my %h is default({})
> {}
> > %h = 3
> 3
> > %h
> {}
> > %h
> {b => 3}
>
> The array/hash variable's default is an empty array/hash literal. If
# New Ticket Created by Andrew Buchanan
# Please include the string: [perl #132053]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=132053 >
> my @h is default([])
[]
> @h[0].push: 3
[3]
> @h
[]
> @h[0]
[3]
> my %h is default(
Heh.
FWIW we had this since forever:
https://gist.github.com/Whateverable/78168042a011e01fc768c042b0d91898
On 2017-09-09 19:53:53, tomentiru...@gmail.com wrote:
> > my @h is default([])
> []
> > @h[0].push: 3
> [3]
> > @h
> []
> > @h[0]
> [3]
>
> > my %h is default({})
> {}
> > %h = 3
> 3
> > %h
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #130293]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130293 >
moritz: m: my %h is default([]); %h.push: 1; %h.push: 2; say %h
camelia: rakudo-moar 2d019
for that. They are just fudged :-)
>
> Seems to work now:
>
> > my %g; push %g, 5; say %g.perl
> ("gamme" => [5]).hash
>
> Tagging testneeded.
>
> /jnthn
>
Found skipped tests in S09-autovivification/autovivification.t, fixed &
unfudged them.
--
Will "Coke" Coleda
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #84000]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=84000 >
Another newbie question: my %g; %g.[].push(5)
doesn't auto-vivify hash element gamma. S
This test is in t/spec and is currently unfudged.
Closing ticket, thanks for the report!
--
Will "Coke" Coleda
# New Ticket Created by Moritz Lenz
# Please include the string: [perl #76492]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=76492 >
> my %h; %h.push: 5; say %h.perl
Method 'push' not found for invocant of class ''
Expect
ut breaking anything. There are other possible
approaches to the problem. Since it also fixes the problem with
print/say I also include a patch to remove the changes to print that are
no longer needed.
Tests for related conditions were already in array_extending.t so I
include a patch that puts m
On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
> Just stumbled across this, but I can't tell from S09 if this is a bug or
> feature:
>
> $ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl'
> {"a" => undef}
It's a bug. In order to simplify the slicing implementation
Rakudo currently aut
On Wed, Dec 31, 2008 at 08:06:48AM -0800, Ovid wrote:
: Just stumbled across this, but I can't tell from S09 if this is a bug or
feature:
:
: $ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl'
: {"a" => undef}
Definitely bug. Rvalues aren't supposed to autovivify.
Larry
Just stumbled across this, but I can't tell from S09 if this is a bug or
feature:
$ ./perl6 -e 'my %foo; if %foo {}; say %foo.perl'
{"a" => undef}
I wasn't expecting auto-vivification there. The examples in S09 use HoH
instead of a flat hash:
But these bindings do autovivify:
# New Ticket Created by Ilya Belikin
# Please include the string: [perl #61740]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=61740 >
Hi!
r34346:
> my %h; %h = 1;
Method 'postcircumfix:{ }' not found for invocant of class
ior is to immediately throw an exception here.
Your analysis is certainly right in this case, but note that it doesn't
work in other cases either:
> "a" ~~ /a/; say $
get_pmc_keyed() not implemented in class 'Undef'
> my %h; say %h
get_pmc_keyed() not implemented in cla
27;t change the semantics:
"this is an hash of sets"
...
"this is what a set contains"
vs.
"this is a hash"
...
"if there is no set make one, and this is what a set contains"
but just the syntax.
&g
Today I wrote some perl 5 code that looked like this:
my %index_by_x;
my %index_by_y;
my %index_by_z;
foreach my $thing (@things){
( $index_by_x{$thing->x_value} ||=
Set::Object->new)->insert($thing);
( $index_by_y{$thing->y_value}
ooey!"
> : if exists $a{b}'
> :
> : perlfunc says:
> :
> : This surprising autovivification in what does not at first--or
> : even second--glance appear to be an lvalue context may be fixed
> : in a future release.
>
> I sure hope so. Perl 5 confuses reference
On Mon, Sep 08, 2003 at 11:18:12AM +0200, Paul Johnson wrote:
: By the way, I trust this will be addressed (if it hasn't been already):
:
: perl5 -le 'print "gah!" if exists $a{b}{c}; print "phooey!" if exists $a{b}'
:
: perlfunc says:
:
: This surprising a
rust this will be addressed (if it hasn't been already):
perl5 -le 'print "gah!" if exists $a{b}{c}; print "phooey!" if exists $a{b}'
perlfunc says:
This surprising autovivification in what does not at first--or even
second--glance appear to be an lvalue c
rtually no" because one could make the argument that you don't
: know if we wanted a standard array or a typed one.)
I would not tie autovivification to typing. Autovivification only
makes sense when there's an existing value you need to construct
a location for, so it really only makes
--
On Mon, 11 Nov 2002 13:02:12
Brent Dax wrote:
>Erik Steven Harrison:
># >I think that, if Perl can determine the type with virtually no
># >ambiguity, it should autovivify.
>#
># Actually, this behavior has already (mostly) been decided over in P6
># language. It was decided (and I agre
Erik Steven Harrison:
# >I think that, if Perl can determine the type with virtually no
# >ambiguity, it should autovivify.
#
# Actually, this behavior has already (mostly) been decided over in P6
# language. It was decided (and I agree) that the Perl 5 behavior of
Can you give me a link or a
e concept
># is being taught at a time. Probably.
>
>OK. I'm trying to do that in the stuff I'm writing.
>
># > =head3 Autovivification
># > @{%anagrams{$key}}.push $word;
># > $undefined_var[$idx]=$scalar;
>#
># Hmm, not a clue. I could
#x27;m writing.
# > =head3 Autovivification
# > @{%anagrams{$key}}.push $word;
# > $undefined_var[$idx]=$scalar;
#
# Hmm, not a clue. I could argue that one both ways. Perhaps (thinking
# aloud) they only autovivify if you've explicitly called out
# the exact t
ldoc writing
style (booklike, informal) is probably exactly what we want, yes? We'll
just break it up into *much* smaller individual sections, so that only
one concept is being taught at a time. Probably.
> =head3 Autovivification
> @{%anagrams{$key}}.push $word;
> $undefined_va
I was writing up some docs (in a perldoc-like style--we can always
change the form later, but the content is important), and started
working on documenting references. I ended up with this bit:
*** BEGIN DOCS ***
=head3 Autovivification
Actually, one of the features of the extra-sigil
gt; > reference to an undefined substructure sets a flag and saves the expression
> > for the lvalue, returning undef whenever evaluated in a read-only context
> > and autovivifying when necessary to write to the lvalue?
> >
> > Deven
>
>
> Lazy autovivification could
the expression
> for the lvalue, returning undef whenever evaluated in a read-only context
> and autovivifying when necessary to write to the lvalue?
>
> Deven
Lazy autovivification could work by adding an on-assignment magic to
the previously nonexistent SV, which details the crea
On Sat, 23 Dec 2000, Graham Barr wrote:
> This has been discussed on p5p many many times. And many times
> I have agreed with what you wrote. However one thing you did not mention,
> but does need to be considered is
>
> func($x{1}{2}{3})
>
> at this point you do not know if this is a read o
This has been discussed on p5p many many times. And many times
I have agreed with what you wrote. However one thing you did not mention,
but does need to be considered is
func($x{1}{2}{3})
at this point you do not know if this is a read or write access as
the sub could do $_[0] = 'fred'. If th
def
1 undef
2 undef
3 ARRAY(0x829a554)
empty array
Now, I understand why this happens, but is it really a good thing that it
happens in the first? We're not storing into the nonexistent substructures
(in which case you DO want autovivification, of course), only attempting to
a
32 matches
Mail list logo
