Re: pull & put (Was: Angle quotes and pointy brackets)
On Mon, 06 Dec 2004 12:22:22 GMT, Smylers <[EMAIL PROTECTED]> wrote: David Green writes: I guess we could always use prepend/append, pull/pop. No! C and C are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Yeah. C and C are old and glorious ones (asm comes to mind), and C is too (even DOS .bat files used it, AFAIR), and it's a one of the most used perl5 CORE:: ops (it's more common than other three) .. And I like to shift :) the only doubtful word for me is unshift. Althought I would be pretty happy if we leave it as is, C is nice and short. but please don't swap meanings of old ops! if old push suddenly would try to unshift something, it could bring some perl5 programmers to hospital.
Re: pull & put (Was: Angle quotes and pointy brackets)
On Mon, 6 Dec 2004 11:34:24 -0800, Larry Wall <[EMAIL PROTECTED]> wrote:
> Though it's awfully tempting to fill in the holes in the periodic table:
>
> ($a, $b, $c) = @foo *<< 3;
>
> And then just say all the corresponding unaries default to 1 (or the arity
> of the left):
>
> $bit = +<< $number; # $number +<< 1
> $graph = ~<< $string; # chip()/chimp()
> $whether = ?<< $boolean;# presumably clears $boolean
> $elem = *<< $iterator; # shift $iterator
Well, that's interesting.
> I suppose unary *>> would mean pop. Blurch. Let's stick with the binaries,
> if we add 'em at all. I do think
>
> foo( @bar *<< 3 )
> foo( @bar *>> 3 )
Hrm... if you're thinking of going that way, I'd rather have a
lazy-assignment/destructive-pipe operator of some sort:
($a,$b) <== [EMAIL PROTECTED]; # splice(@bar, 0, 2)
($a, $b) ==> [EMAIL PROTECTED] # splice(@bar, 0, 0, $a, $b)
[EMAIL PROTECTED] ==> ($a, $b); # splice(@bar, -2)
[EMAIL PROTECTED] <== ($a, $b); # splice(@bar, @bar, 0, $a, $b);
Of course, with something indicating the desire to modify the array. I
don't know that [EMAIL PROTECTED] would be right for that, but I dunno. Just an
idea.
I'd want some way of telling the array to lazily add/remove elements
as part of the pipe operator, which would make:
foo <== [EMAIL PROTECTED]; # REMOVE however many elements from the front of
@bar
as foo() wants
However, this would lead to me thinking about this sequence:
[EMAIL PROTECTED] ==> map ==> grep ==> @whatever;
as:
while pop @this { ... unshift @that, $_ }
Which would be interesting (bad) for performance
Ashley
Re: pull & put (Was: Angle quotes and pointy brackets)
stuff & grab :-) -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- > On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: > : But I'd be willing to rename them to get/put. > > If I went with "get", the opposite would be "unget" for both historical > and huffmaniacal reasons. > > Larry
Re: pull & put (Was: Angle quotes and pointy brackets)
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
Re: pull & put (Was: Angle quotes and pointy brackets)
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?
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?
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)
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.
=Austin
Re: pull & put (Was: Angle quotes and pointy brackets)
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. : : But "get" has too strong a class accessor connotation in most OO. : : "unpull?" ;-) 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.) Though it's awfully tempting to fill in the holes in the periodic table: ($a, $b, $c) = @foo *<< 3; And then just say all the corresponding unaries default to 1 (or the arity of the left): $bit = +<< $number; # $number +<< 1 $graph = ~<< $string; # chip()/chimp() $whether = ?<< $boolean;# presumably clears $boolean $elem = *<< $iterator; # shift $iterator That would mean that we couldn't use those unaries in front of <<...>> though. I suppose unary *>> would mean pop. Blurch. Let's stick with the binaries, if we add 'em at all. I do think foo( @bar *<< 3 ) foo( @bar *>> 3 ) might actually be clearer than foo( splice(@bar,0,3) ) foo( splice(@bar,-3,3) ) Also, note that neither of the latter examples means the same as foo( pop(@bar,3) ) since pop would presumably pop them in reverse order from splice. We also get all the rotates if we allow *<<< and *>>>. On the other hand, if anyone suggests a list xor: @foo *^ @bar I'll ask whether they mean @foo »+^« @bar @foo »~^« @bar @foo »?^« @bar @foo »*^« @bar Larry
Re: pull & put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 01:25:29PM -0600, Rod Adams wrote: > Dan Brian wrote: > > >>If I went with "get", the opposite would be "unget" for both historical > >>and huffmaniacal reasons. > > > > > >But "get" has too strong a class accessor connotation in most OO. > > > >"unpull?" ;-) > > > > > pushf/popf. f is for "front". Ew! I'd prefer :head/:tail modifiers to push/pop over that. But ... > But I still don't see anything wrong with shift/unshift. Neither do I. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: pull & put (Was: Angle quotes and pointy brackets)
Dan Brian wrote: If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. But "get" has too strong a class accessor connotation in most OO. "unpull?" ;-) pushf/popf. f is for "front". But I still don't see anything wrong with shift/unshift. I'd prefer to avoid having a group of words that all mean about the same thing, but keeping them straight requires some memory trick. I program in too many languages to keep my mnemonics straight. There's going to be enough fun with is/has/does/but. For reference, I always have to do a 'perldoc perlvar' when I need a P5 $. -- Rod Adams
Re: pull & put (Was: Angle quotes and pointy brackets)
If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. But "get" has too strong a class accessor connotation in most OO. "unpull?" ;-)
Re: pull & put (Was: Angle quotes and pointy brackets)
On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: : But I'd be willing to rename them to get/put. If I went with "get", the opposite would be "unget" for both historical and huffmaniacal reasons. Larry
Re: pull & put (Was: Angle quotes and pointy brackets)
Smylers wrote: Larry Wall writes: But then are we willing to rename shift/unshift to pull/put? Yes. C is a terrible name; when teaching Perl I feel embarrassed on introducing it. No! But I'd be willing to rename them to get/put. 'Pull' is the opposite of 'push', but 'pop' already works. Given the nature of many of the other changes in Perl 6, completely changing regexps for example, renaming a couple of functions seems minor. Agreed. Smylers =Austin
Re: pull & put (Was: Angle quotes and pointy brackets)
David Green writes: > I guess we could always use prepend/append, pull/pop. No! C and C are a well-defined pair, not just in Perl, for dealing with stacks; we should keep those as they are. (And no synonyms, before somebody suggests any!) Smylers
Re: pull & put (Was: Angle quotes and pointy brackets)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke Palmer) wrote: >But what we'd really like to do is: given the user knows what push/pop >do, what would they *guess* to mean shift (I tend to think that this >is a very good technique for naming). >And, well, I'm thinking pull. So it's a toss-up between shift/unshift >and put/pull. I think "push" and "pull" fairly naturally could be taken to refer to the front of an array; you might even argue that the natural direction for something to "pop" is away from you (i.e. off the back) The problem I have with push/pull referring to opposite ends is that the same person is doing the pushing and the pulling, so both words ought to apply to the same end of the array (the front end), which violates the comp-sci-y expectations. (And although normally I'm happy to chuck CS jargon out the window, because so much of it is really bad, the push/pop thing goes pretty deep.) Not to mention everyone coming from Perl <6. Though if we had "push" without "pop", that wouldn't be as bad. I guess we could always use prepend/append, pull/pop. You might not guess what they meant, but once you know, I think the meanings are reasonably "obvious". (Dislike typing though I may, I'm hesitant to suggest "prep" and "app".) Hm, actually counting letters, "prepend" is no longer than "unshift" (and if not a real word, is at least used as one more often than "unshift" is). In fact, prepend/append/pull/pop altogether are only one letter more than push/pop/shift/unshift. So those are now officially my preferred replacements. But if we want something that makes it immediately obvious what end of the array we're messing with.. something visually obvious... ooh, this sounds like a job for Unicode!! (Just kidding. Sort of.) We've already got those lovely pipe operators to build on, and they can already do assignment; if you can go from = to +=, why not from <== to +<==? @a <== $foo, $bar; # @a=($foo, $bar) $foo, $bar ==> @a; # ditto @a +<== $foo, $bar; # push @a, $foo, $bar $foo, $bar ==>+ @a; # unshift @a, $foo, $bar @a -==> $foo, $bar; # ($bar, $foo) = (pop @a, pop @a) $foo, $bar <==- @a; # ($foo, $bar) = (shift @a, shift @a) The + or - tells you whether you're adding on or taking away, and the arrow points to (or from) the end of the array you're doing it to. (I know some people will hate four symbols in a row. That's why we have seven-letter alternatives like "prepend".) I was going to say an advantage over old-fashioned pop/shift is that you could remove more than one element at a time, but there isn't any reason for their P6 versions not to return as many items as are want()ed, is there? The bad news (assuming anyone actually thinks there's anything good in the above suggestion) is that since +<== and friends are assignment operators, you can't just do foobar( @a-==>, $x, $y). Um, unless -==> could be made to work as a unary operator. Which even I don't think I like. =) So we should keep the wordy versions too. -David "pull goes the weasel" Green
Re: pull & put (Was: Angle quotes and pointy brackets)
It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. As a mnemonic for remembering which side push/pull operate on, I agree. (A stalled car etc.) It would be nice if the corresponding functions could similarly be opposed without the potential confusion for beginners, but I realize that may not be possible, and your example is at least convincing that it's better than shift/unshift.
Re: pull & put (Was: Angle quotes and pointy brackets)
Dan Brian writes: > Having push and pull operate on opposite ends of an array strikes me > as more confusing than even shift. It makes good sense to me -- if we're trying to move a piano from you to me then either you can push or your end or I can pull on my end: we're operating on different ends of it, but the effect in both cases is moving in one direction. Now instead of a piano imagine one of those conveyor belts that you get at supermarket checkouts: you push your goods on one-end, and the cashier pulls them off the other. When the cashier pulls one item off that unbreaks the light beam to the sensor, which triggers the motor, and all the other items get pulled along too, moving one place along. Smylers
Re: pull & put (Was: Angle quotes and pointy brackets)
If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending "shell heritage". That actively opposes sixty years of computer science terminology setting "push" and "pop" in opposition. I'm not objecting to pop, but pull in opposition to push, on the other side of the array.
Re: pull & put (Was: Angle quotes and pointy brackets)
Dan Brian writes: > If there's a willingness to rename shift/unshift, why not consider > going a bit further (and offend shell heritage) to note that pull/put > aren't really linguistically opposed either (unlike push/pull). Why not > rename pop to pull, and use something like put/take for shift/unshift? > Having push and pull operate on opposite ends of an array strikes me as > more confusing than even shift. When it comes to adding and removing > elements, shouldn't there be semantic opposition for functions that > operate on the same end? I don't think that's a good time. It kills the array-as-stack idiom, which, well, everybody uses all the time. I don't mind the linguistic nonopposition of pull/put. The main thing I don't like is the alliteration between push/pop. That makes for very difficult mnemonics. Obviously, the CS-literate can just remember that they're the nonstack ops, but many Perlers are Shellers and Adminers, without being CSers. I've actually been happy with shift/unshift. But what we'd really like to do is: given the user knows what push/pop do, what would they *guess* to mean shift (I tend to think that this is a very good technique for naming). And, well, I'm thinking pull. So it's a toss-up between shift/unshift and put/pull. Luke
Re: pull & put (Was: Angle quotes and pointy brackets)
On Sat, 4 Dec 2004 23:33:24 -0700, Dan Brian <[EMAIL PROTECTED]> wrote: > If there's a willingness to rename shift/unshift, why not consider > going a bit further (and offend shell heritage) to note that pull/put > aren't really linguistically opposed either (unlike push/pull). Why not > rename pop to pull, and use something like put/take for shift/unshift? That goes way beyond offending "shell heritage". That actively opposes sixty years of computer science terminology setting "push" and "pop" in opposition. (Well, maybe not *sixty* years, but you get the idea.) -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker "I might be an idiot, but not a stupid one." --c.l.p.misc (name omitted to protect the foolish)
Re: pull & put (Was: Angle quotes and pointy brackets)
C's only virtue, IMHO, is that it's clearly the inverse of C. But I think the spelling and aural relationship between C, C, C, and C is clear enough to negate that. But then, I'm a little biased. Except that push and pull are logical opposites linguistically, but not in standard CS parlance. could be very confusing. There's a possibility of using C and C for enqueue/dequeue, except that C == C in standard implementations. So C and C? yeck. If there's a willingness to rename shift/unshift, why not consider going a bit further (and offend shell heritage) to note that pull/put aren't really linguistically opposed either (unlike push/pull). Why not rename pop to pull, and use something like put/take for shift/unshift? Having push and pull operate on opposite ends of an array strikes me as more confusing than even shift. When it comes to adding and removing elements, shouldn't there be semantic opposition for functions that operate on the same end? (I realize that take is already ... taken, for control structures.)
Re: pull & put (Was: Angle quotes and pointy brackets)
Brent 'Dax' Royal-Gordon wrote: Smylers <[EMAIL PROTECTED]> wrote: Yes. C is a terrible name; when teaching Perl I feel embarrassed on introducing it. C's only virtue, IMHO, is that it's clearly the inverse of C. But I think the spelling and aural relationship between C, C, C, and C is clear enough to negate that. But then, I'm a little biased. Except that push and pull are logical opposites linguistically, but not in standard CS parlance. could be very confusing. There's a possibility of using C and C for enqueue/dequeue, except that C == C in standard implementations. So C and C? yeck. -- Rod Adams
Re: pull & put (Was: Angle quotes and pointy brackets)
Smylers <[EMAIL PROTECTED]> wrote: > Yes. C is a terrible name; when teaching Perl I feel > embarrassed on introducing it. C's only virtue, IMHO, is that it's clearly the inverse of C. But I think the spelling and aural relationship between C, C, C, and C is clear enough to negate that. But then, I'm a little biased. -- Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker "I might be an idiot, but not a stupid one." --c.l.p.misc (name omitted to protect the foolish)
Re: pull & put (Was: Angle quotes and pointy brackets)
Larry Wall writes: > But then are we willing to rename shift/unshift to pull/put? Yes. C is a terrible name; when teaching Perl I feel embarrassed on introducing it. Given the nature of many of the other changes in Perl 6, completely changing regexps for example, renaming a couple of functions seems minor. Smylers
