On Thu, Sep 18, 2008 at 10:21 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote: >> On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell <[EMAIL PROTECTED]> >> wrote: >> > On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: >> >> > "Aggregating coroutine" and "aggregating yield" aren't nearly as zippy >> >> > as 'gather' and 'take', but they're more meaningful to a broader >> >> > audience, which may help the feature spread. >> > >> > I don't buy this. The Perl 6 terms are well chosen, and as soon as you >> > know what they mean in the context of programming, you won't forget. >> > The other versions ... well, let's leave it at "easy to forget". (OK, >> > one more thing -- the word "coroutine" scares people. "Gather" does >> > not.) >> > >> >> I'm rather hoping and expecting that "gather" and "take" become >> >> the meaningful names for this feature, much like "grep" started >> >> out as a Unix shell command but is now the language-agnostic term for >> >> "extract things from a list matching a pattern". >> > >> > Now *this* I agree with. The first system to make a feature standard >> > gets first try at standardizing the name. If they've chosen the name >> > well, there's a decent chance it will stick. >> >> what some refer to as "traits", perl 6 calls "roles". >> >> what some refer to as "associative arrays", perl calls "hashes". >> [...] >> we need to be precise in naming constructs, rather than using common names. >> scientists call a chanterelle mushroom by its proper name, >> "Cantharellus cibarius". > > Other languages have adopted the Perl shortname of "hash" as well, > including Ruby and this odd little creature known as "Parrot". Perhaps > we should rename Parrot's "Hash" class to "AssociativePMCArray"? 1/2 ;-) > >> we should call gather and take by their proper names where they're >> defined. "aggregating coroutine" is more precise and descriptive than >> is "gather", however "gather" is much easier to say in polite company, >> and is therefore a better name to use at the language level. > > By this reasoning, we should also change the other exceptions: > > .CONTROL_RETURN => .CONTROL_SUB_RETURN (or .CONTROL_SUB_EXIT) > .CONTROL_BREAK => .CONTROL_LOOP_EXIT > .CONTROL_CONTINUE => .CONTROL_LOOP_NEXT > > and perhaps add .CONTROL_LOOP_REPEAT there as well. Note that I'm not at > all opposed to this -- if we're going to do it for one, we really > ought to do it for all. > agreed. precision is of little benefit unless it's consistent across related functionality.
~jerry
