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: Angle quotes and pointy brackets
On Thursday, December 2, 2004, 10:08:31 AM, you (mailto:[EMAIL PROTECTED]) wrote: On Tue, 30 Nov 2004, Austin Hastings wrote: How about just having C system() return a clever object with .output and .err methods? interesting... Michele Prior art of this on Windows... http://msdn.microsoft.com/library/en-us/script56/html/wslrfExecMethod.asp (the respective properties on the returned WshScriptExec instance being .StdOut and .StdErr.) -- Richard mailto:[EMAIL PROTECTED]
Re: Required whitespace issues.
Larry Wall wrote: On Sat, Dec 04, 2004 at 08:55:00PM -0600, Rod Adams wrote: : $x ==$foo; # $x == $foo; $x = =$foo; : @x ==$foo; # @x = =$foo; @x == $foo; : $x//=$foo; # $x // =$foo; $x //= $foo; : [EMAIL PROTECTED]; # $x ** [EMAIL PROTECTED]; $x **= @y; In each of those cases the longest-token rule comes into effect. That's not only consistent, but standard CompSci for the last 30 years or so. The only person who will get burned on those is someone who insists on *not* putting whitespace in front of unary = when it would be ambiguous. I have negative sympathy for such people. Well said! Although I by no means dispute that longest token rule is a long term standard in language design, I will claim that many programmers, including myself before this, are unaware of it. So I will now change my concerns to: The longest-token rule needs to be mentioned in S03, and explained in a future perlop.pod. -- Rod Adams
Re: pull put
RA == Rod Adams [EMAIL PROTECTED] writes: RA Brent 'Dax' Royal-Gordon wrote: Smylers [EMAIL PROTECTED] wrote: Yes. Cunshift is a terrible name; when teaching Perl I feel embarrassed on introducing it. Cunshift's only virtue, IMHO, is that it's clearly the inverse of Cshift. But I think the spelling and aural relationship between Cpush, Cpop, Cpull, and Cput is clear enough to negate that. But then, I'm a little biased. RA Except that push and pull are logical opposites linguistically, but RA not in standard CS parlance. could be very confusing. RA There's a possibility of using Cenq and Cdeq for enqueue/dequeue, RA except that Cdeq == Cpop in standard implementations. RA So Cenq and Cshift? yeck. what about get/put for queue stuff? they don't conflict with push/pop/(un)shift so we can keep them. they would be synonyms for shift/push on arrays but do the right thing for queues and other unlimited things. and get/put are also an historical pair of computer terms that are well known (pl/i and others). and they are nice and short too so they make huffman feel good. :) so you could use get/put on arrays or queues but only them on queues. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Required whitespace issues.
On Sun, Dec 05, 2004 at 10:02:16AM -0600, Rod Adams wrote: Although I by no means dispute that longest token rule is a long term standard in language design, I will claim that many programmers, including myself before this, are unaware of it. Programmers tend to follow the rule even when they are not consciously aware of it. They usually become consciously aware of it the first time they try using a compiler generator to create a lexer, and discover that they need to define the longer tokens before the shorter ones in the configuration file. So I will now change my concerns to: The longest-token rule needs to be mentioned in S03, and explained in a future perlop.pod. For sure, stating it clearly and unambiguously will probably help those new to programming, and maybe help those who want to extend perl 6 by defining new grammer rules. -- Jon Shapcott [EMAIL PROTECTED] This is the Space Age, and we are Here To Go - William S. Burroughs
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: 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: specifying the key Type for a Hash
Larry Wall writes: But pretty much every time I've introduced synonyms into Perl I've come to regret it. But hey, if I introduce *different* synonyms this time, does that count as making a new mistake? No! Avoid synonyms. They're initially tempting, because then everybody gets to pick the one he/she wants to use, but then it turns out you need to learn all of them so as to read other people's code, and that's worse than not having them at all. 'MySQL' is riddled with them, and they're most inconvenient! Smylers
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.
