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 ref
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
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 wo
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 ;-)
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 rightmos
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];
> > Pe
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[100
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). IMH
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
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
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 lik
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 wor
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.
--
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
14 matches
Mail list logo
