negative index in arrays
Stephen Rawls
accross a small semantic problem. I suppose this
might be language level (and thus Larry's turf?), but
how should the VM handle negative indecis? It already
handles the simple cases when the absolute value of
the index is less than the container size, but it does
no bounds checking beyound that. For instance:
new P0, .PerlArray
set P0, 3
set P0[0],1
set P0[1],2
set P0[2],3
set I0, P0[-1] #set I0 to 3
set I0, P0[-10] #segfaults on my machine
My question: do we want the latter case to return an
error, or should we try to DTRT and in the above case
set I0 to 3. All it takes is changing the if in all
the lines like:
if (ix < 0) ix += SELF->cache.int_val
to a while. I just wanted to see what the general
consensus is, since I want the Tuple pmc to do the
same thing in this respect as the PerlArray pmc.
Thanks!
Stephen Rawls
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
Aldo Calpini
> since I want the Tuple pmc to do the same thing in
> this respect as the PerlArray pmc.
just my opinion, but I don't want this. it would be
PerlTuple then. let's keep this stuff at a higher level.
the only and one reason I see because one would implement
tuples instead of arrays is: speed. no need to cope with
dynamic memory allocation, no need to grow or shrink,
se there should also be no need to check for syntactic
sugar like negative indices.
cheers,
Aldo
__END__
$_=q,just perl,,s, , another ,,s,$, hacker,,print;
Stephen Rawls
> there should also be no need to check for
> syntactic sugar like negative indices.
True, I suppose if a language REALLY wanted this, it
could be implemented on the interpreter level.
<changing subject>
Also of note, instead of having TUPLE1 + TUPLE2 act as
arrays, and return the sum of their sizes, I am
treating it like this: (a1, a2, ... , an) + (b1, b2,
.... , bn) = (a1 + b1, a2 + b2, ... , an + bn)
This is (of course) not restricted to addition. I
thought I'd check and see if you all feel that should
be the default implementation, though. Or maybe we
need a special HyperTuple pmc too?
cheers,
Aldo Calpini
> Also of note, instead of having TUPLE1 + TUPLE2 act as
> arrays, and return the sum of their sizes, I am
> treating it like this: (a1, a2, ... , an) + (b1, b2,
> ... , bn) = (a1 + b1, a2 + b2, ... , an + bn)
makes sense to me (and certainly adds some spice to
the cause of tuples instead of arrays :-).
you should also consider the case TUPLE1 + 5 which
should return (a1 + 5, a2 + 5, ... , an + 5).
what do you do if TUPLE1 and TUPLE2 are of different
length?
changing subject again... how is tuple storage
implemented? do they contain only integers (or whatever),
or is the base type definable? I ask this because I
thought it would be nice to have a 4-tuple of type char.
this will nicely represent an IP address, for example
(or do we need an ipaddr.pmc? ;-).
Stephen Rawls
> should return (a1 + 5, a2 + 5, ... , an + 5).
Agreed. I had started to implement this already, but
I've only done the add function so far, since I'm
still testing and waiting for a consensus.
> what do you do if TUPLE1 and TUPLE2 are of different
> length?
Throw an exception. If there are more graceful
solutions, though, I'm open to them.
> changing subject again... how is tuple storage
> implemented? do they contain only integers (or
> whatever), or is the base type definable?
I based it off array.pmc, so you can store
ints/chars/floats/pmcs in it.
Dan Sugalski
>In working on the Tuple pmc (almost done!) I've come
>accross a small semantic problem. I suppose this
>might be language level (and thus Larry's turf?), but
>how should the VM handle negative indecis?
It should pass them on to the PMC directly, which should then handle
them properly.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Stephen Rawls
> should then handle them properly.
Let me rephrase. How should the PerlArray pmc handle
negative indecis when the absolute value of the index
is greater than the size of the array. Here are some
examples:
#first set up an array
new P0, .Perl Array
set P0, 3
set P0[0], 1
set P0[1], 2
set P0[2], 3
#now, what do these accesses produce?
P0[-1] => P0[2] => 3
P0[-3] => P0[0] => 1
P0[-5] => ?
here's my take on how to DTRT
-5 + 3 = -2, -2 + 3 = 1, so
P0[-5] => P0[1] => 2
Like I said in the earlier message, this would only
need the 'if's changed to 'while's to work. But,
right now the PerlArray.pmc code does this:
if (ix < 0) ix += SELF->cache.int_val
So, if ix < -SELF->cache.int_val then the code tries
to use a negative value to access the array element in
the C code. This is obviously wrong. My question is
should this raise an internal exception, or should
there be some DWIMery inside PerlArray.pmc.
cheers,
Sean O'Rourke
> > It should pass them on to the PMC directly, which
> > should then handle them properly.
>
> Let me rephrase. How should the PerlArray pmc handle
> negative indecis when the absolute value of the index
> is greater than the size of the array.
IMHO it would be most consistent with the way autovivification of
positive indices works to extend the array to the left and set the first
element, e.g.
@a = (1);
@a[-3] = 2;
# @a == (2, undef, 1)
Perl 5 says this is a "modification of a non-creatable array value",
though.
/s
Stephen Rawls
> > Let me rephrase. How should the PerlArray pmc
> > handle negative indecis when the absolute value of
> > the index is greater than the size of the array.
>
> IMHO it would be most consistent with the way
> autovivification of positive indices works to extend
> the array to the left and set the first element,
e.g.
>
> @a = (1);
> @a[-3] = 2;
> # @a == (2, undef, 1)
>
Hmmm. I hadn't even thought about expanding left and
shifting everything else right. I like your way, so
.... if that's what everyone wants, I'll try my hand at
a patch.
Dan Sugalski
>--- Sean O'Rourke <soro...@cs.ucsd.edu> wrote:
>> > Let me rephrase. How should the PerlArray pmc
>> > handle negative indecis when the absolute value of
>> > the index is greater than the size of the array.
>>
>> IMHO it would be most consistent with the way
>> autovivification of positive indices works to extend
>> the array to the left and set the first element,
>e.g.
>>
>> @a = (1);
>> @a[-3] = 2;
>> # @a == (2, undef, 1)
>>
>
>Hmmm. I hadn't even thought about expanding left and
>shifting everything else right. I like your way, so
>... if that's what everyone wants, I'll try my hand at
>a patch.
No, I don't think this is appropriate. The PerlArray class implements
Perl arrays, and should implement their semantics.
Graham Barr
> > It should pass them on to the PMC directly, which
> > should then handle them properly.
>
> to use a negative value to access the array element in
> the C code. This is obviously wrong. My question is
> should this raise an internal exception, or should
> there be some DWIMery inside PerlArray.pmc.
Well in perl today.
print $a[-2];
just gives undef and @a is unchanged
$a[-2] = 1;
dies with
Modification of non-creatable array value attempted, subscript -2 at -e line 1.
But it seems to me that parrot has not concept of lvalue/rvalue use
when fetching an element from an aggregate.
Graham.
Sean O'Rourke
> No, I don't think this is appropriate. The PerlArray class implements
> Perl arrays, and should implement their semantics.
It implements Perl 6 arrays, though. If it's a useful semantic extension
(restrictions are another matter), I don't see why "perl 5 doesn't do it"
is a reason to leave it out.
/s
Stephen Rawls
>> [snip]
> No, I don't think this is appropriate. The PerlArray
> class implements
> Perl arrays, and should implement their semantics.
Let me rephrase again :) What should the semantics
for Perl arrays be?
Dan Sugalski
Not with fetching, no. The second example would be something like:
set P0[-2], 1
in assembly.
Dan Sugalski
Oh, "Perl 5 doesn't do it" is a lousy reason. "Perl 6 doesn't do it"
however is. So... Larry? Semantic call for you on the white courtesy
telephone!
Graham Barr
> At 10:24 PM +0100 8/1/02, Graham Barr wrote:
> >On Thu, Aug 01, 2002 at 02:11:27PM -0700, Stephen Rawls wrote:
> >> > It should pass them on to the PMC directly, which
> >> > should then handle them properly.
> >>
> >> So, if ix < -SELF->cache.int_val then the code tries
> >> to use a negative value to access the array element in
> >> the C code. This is obviously wrong. My question is
> >> should this raise an internal exception, or should
> >> there be some DWIMery inside PerlArray.pmc.
> >
> >Well in perl today.
> >
> > print $a[-2];
> >
> >just gives undef and @a is unchanged
> >
> > $a[-2] = 1;
> >
> >dies with
> >
> >Modification of non-creatable array value attempted, subscript -2 at
> >-e line 1.
> >
> >But it seems to me that parrot has not concept of lvalue/rvalue use
> >when fetching an element from an aggregate.
>
> Not with fetching, no.
Hm, That may result in arrays being extended unnecessarily, which
would also be a change in semantics, or array access for rvalues
being multiple ops, checking the array length first.
> The second example would be something like:
>
> set P0[-2], 1
>
> in assembly.
Right, which would raise an exception if the array had less than 2 elements.
Graham.