At 04:28 PM 8/2/2002 +0200, Haegl wrote:
On 2002/08/02 16:11:26 Nicholas Clark [EMAIL PROTECTED] wrote:
It does on reading. I forget the eloquent explanation about the how or
why, but all references bar the leftmost are vivified. (Even inside
defined). In effect, all bar the last reference
Dan Sugalski wrote:
At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
fetching an element out of bound changes the
length of the array. but should this really happen?
Because that's the way Perl's arrays work. Joys of
autovivification.
I have to disagree. the corresponding Perl script
does not
Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
It all depends. :-)
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
print scalar(a);
101
10001
Perl has to autoviv if it has to drill down.
--
John Douglas Porter
John Porter wrote:
It all depends. :-)
[...]
Perl has to autoviv if it has to drill down.
good point. but since we don't have multidimensional
array access right now (at least AFAIK), this seems
to be a non-issue. I don't know if p6 will autovivify
the way p5 does (and I hope not). IMHO,
John Porter wrote:
Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
This _writes_ to a[1] by generating the entry:
P0, 100
P1 = new .PerlArray
P1 = 0
P0[1] = P1
I0 =
On Fri, Aug 02, 2002 at 03:11:41PM +0200, Leopold Toetsch wrote:
John Porter wrote:
Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
Perl has to autoviv if it has
On 2002/08/02 16:11:26 Nicholas Clark [EMAIL PROTECTED] wrote:
It does on reading. I forget the eloquent explanation about the how or
why, but all references bar the leftmost are vivified. (Even inside
defined). In effect, all bar the last reference are in lvalue context -
only the rightmost is
That Haegl was actually me, Florian Haeglsperger (actually Häglsperger, but I don't
mind).
I accidently sent the mail using the wrong e-mail account. It is not my intention to
hide
myself behind a stupid nickname like rEaLkEwLgUy2o0o or something like that ;-)
All~
It does on reading. I forget the eloquent explanation about the how or
why, but all references bar the leftmost are vivified. (Even inside
defined). In effect, all bar the last reference are in lvalue context -
only the rightmost is rvalue.
The explanation is the part that would have
At 4:28 PM +0200 8/2/02, Haegl wrote:
On 2002/08/02 16:11:26 Nicholas Clark [EMAIL PROTECTED] wrote:
It does on reading. I forget the eloquent explanation about the how or
why, but all references bar the leftmost are vivified. (Even inside
defined). In effect, all bar the last reference are in
take this little assembler program:
new P1, .PerlArray
set P1, 100
bsr GETLEN
set I0, P1[0]
print P1[0]=
print I0
print \n
bsr GETLEN
set I0, P1[1]
print P1[1]=
print I0
At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
fetching an element out of bound changes the
length of the array. but should this really happen?
why does perlarray.pmc act like this:
Because that's the way Perl's arrays work. Joys of autovivification.
--
On Thu, Aug 01, 2002 at 03:42:19PM -0400, Dan Sugalski wrote:
At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
fetching an element out of bound changes the
length of the array. but should this really happen?
why does perlarray.pmc act like this:
Because that's the way Perl's arrays work. Joys
At 9:04 PM +0100 8/1/02, Graham Barr wrote:
On Thu, Aug 01, 2002 at 03:42:19PM -0400, Dan Sugalski wrote:
At 5:28 PM +0200 8/1/02, Aldo Calpini wrote:
fetching an element out of bound changes the
length of the array. but should this really happen?
why does perlarray.pmc act like this:
14 matches
Mail list logo
