On Mon, Dec 06, 2004 at 03:50:42PM -0500, Austin Hastings wrote:
: Larry Wall wrote:
:
: >On Mon, Dec 06, 2004 at 11:52:22AM -0700, Dan Brian wrote:
: >: >If I went with "get", the opposite would be "unget" for both historical
: >: >and huffmaniacal reasons.
: >
: >
: Why? (I get the huffman, not the history.) Is it just a nod to unshift?
Try "man ungetc".
: >Given the existence of a unary = for abbreviated use, I'd probably
: >stick with shift/unshift. (Presumably changing the semantics of
: >shift from p5 to be list/scalar/n-ary context sensitive, so you'd
: >have to write "scalar shift" to get Perl 5's shift semantics
: >in list context.)
: >
: >
: What about add/remove?
Backwards Huffman, considering removal happens more often.
: sub unshift(@a, [EMAIL PROTECTED])
: {
: @a.add(@items);
: }
:
: We could add :head and :tail, with :head the default, and let push|pop
: be equivalent to (add|remove).assuming(tail => 1)
"remove" is a transitive verb. I think people would take "remove"
to be "remove any occurrences of", and in the absence of any obvious
direct object, "remove this array", or "remove the list of files in
this array".
: As a side note, other than historical consistency, is there a good
: reason for push/pop to use the end of the array? I'd argue that for a
: stack, you only want to "know" one address: @stack[0] -- the 'top' of
: the stack -- and if you ever iterate a stack you're inclined to see the
: items in "distance-from-top" order, making 0..Inf the right array
: sequence. If we're going to reorg the function space, let's huffmanize
: the stack stuff (push/pop/0) and let the other stuff go hang.
For indexable arrays, the front is what you want to nail down, but
that means it's difficult to make unshift efficient. Swapping push/pop
for shift/unshift would make push/pop rather inefficient. And the top
of your stack can just as easily be @stack[-1] as it is now.
I don't see much reason to change what we have currently unless we
decided "shift" was too long, and it isn't if we have unary = for
interators, and real function args to take away most of "my $arg = shift;".
Appearances to the contrary notwithstanding, I'm not trying to break
Perl 5 constructs just for the heck of it.
Larry
