On Fri, Sep 01, 2000 at 08:38:18PM -0000, Perl6 RFC Librarian wrote:
> =head1 IMPLEMENTATION
>
> I don't know the gory details other than it should be possible.
Thinking in perl5 terms, its going to require a modification to pp_pop
and pp_shift. The simplest way to do it would be for them to simply
call pp_splice if a second argument is given and its greater than 1.
No second argument and 1 are treated as a normal pop()/shift().
Possibly also opcode.pl and ck_shift() in op.c would need to be
modified to account for the new syntax.
> However, there is one implementation detail that occurs to me:
> What should happen when the expression given to C<pop()>, or
> C<shift()> evaluates to a negative number? I see three options:
>
> 1) Nothing. We can only pop/shift positive amounts
> 2) Act as if the number were positive (i.e. pop @array, abs(EXPR))
> 3) C<pop()> would then act as C<shift()> and C<shift()> would
> act as C<pop()>
If pop @array, -1 == shift @array, 1 and shift @array, -1 == pop
@array, 1, and if both Ways To Do It are almost exactly the same, then
there's no value to allowing negative numbers. In most cases I'd
expect passing a negative number to be a mistake on the programmer's
part.
#2 is very bad. Silently correcting a mistake just leads to uncaught
bugs.
#3 I do not like for the same reasons as #2. Accidentally typing a
negative number of pop()s shouldn't silently revert to a shift and
vice-versa. It doesn't add any functionality and its not a
particularly different or interesting way to do it.
#1 is good, assuming it causes an error. It also leaves open the
possibility of reverting to #3 at some later date.
And pop(@array, 0) should do nothing and produce a warning.
Garbage In/Error Out.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
<GuRuThuG> make a channel called Perl, and infest it with joking and
fun....it doesnt make alot of sense.
