Albert asked:
> I hope it's OK for a newbie to comment here.  Why complicate 
> things with three signatures? Why not just:
>     slice(n,m)
> where n=pos & m=length
> so that:
>     slice(0,1)     # slice_low        1st
>     slice(0,3)     # slice_low(3)     1st 3
>     slice(-1,1)    # slice_high       last
>     slice(-3,3)    # slice_high(3)    last 3

Asking such questions isn't bad thing to do! There might be others in the
same situation just too stupid, busy or scared to do the right thing (tm).
If you manage to convince us that such wordiness is bad thing, you can
affect the future of the whole community. Thus, communication and discussion
is not wasted bandwidth and time but really important and almost a
requirement for good evolution.

Well, my easy answer would be 'for readability and writability' (== more cod
able and maintainable).

My longer one, or at least the few I could come up with easily:

1) 
Version using two arguments compared to named version is shifting action
from named functionality to the direction where semantic meaning is hided
inside syntax.

One could ask why stop to slice(0,1) version? We could transform all the
function names to certain numbers and write instead '283(0,1)' and actually
punctuation eases things, so maybe we should get rid of it too.

2)
For TIMTOWTDI ('There Is More Than One Way To Do It', Perl marketed acronym
which Ruby has inherited, IMHO The Very Good Thing). Allowing people to be
as clean as possible doesn't hurt anybody. On the other hand getting rid of
slice(n,m) loses functionality and one can't write 

  array.slice!(*calc_where_to_remove_and_how_many())

So we should really have all those signatures.

3)
For 'Don't repeat yourself'.
The versions you wrote include some unnecessary duplication.

  a = remove_this_many_from_the_end_of_the_array
  slice!(-a, a)

Why would you like to repeat 'a' two times, if you don't have to? 

Ok, if I didn't make my point clear let me show the worse case for the same
thing:

  slice!(-remove_this_many_frm_the_end_of_the_array, 
          remove_this_many_frm_the_end_of_the_array)

Oh, and then you probably noticed you made a spelling error '_frm_' and have
to correct it to two places (mostly non-issue in the era of useful editors,
provided one uses them properly).

This point is contradictory, however, because we're implementing many ways
to do the same thing, so repeating ourselves to some extent.

4)
For this one I'm not even sure, but I could imagine slice_low to be faster
than slice(0,1)  (no unnecessary parameter passing). Since we're
interpreting it (most likely) anyway, this is no big deal.  (And maybe I
have to add that for 'Don't repeat yourself' we would implement this as a
C-routine slice_low calling slice_two_arg(0,1), which actually makes more
overhead than to call slice_two_arg directly).

----

Anyway, it's quite much about the balance. It wouldn't be nice if the
standard libraries are bloated with aliases and signatures thus reserving
all the good variable and function beforehand. Moreover it makes things
harder to learn, code and maintain.

	- Aleksi