On Thu, 2008-09-18 at 10:28 -0700, jerry gay wrote: > 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: > >> what some refer to as "traits", perl 6 calls "roles".
The Perl 6 name is a better, more natural and self-describing name. Larry has a gift for naming, and he puts a lot of effort into making names obvious. I think it's a mistake to ignore that, just because Larry didn't design all of the major dynamic languages himself. > > 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 ;-) I personally agree that 'hash' is by far the better name. But to be fair, it helps that 'hash' is one of the basic data structures taught to every CS student freshman year .... > >> we should call gather and take by their proper names where they're > >> defined. "aggregating coroutine" is more precise and descriptive than > >> is "gather", If you had no idea what an 'aggregating coroutine' was, would your first guess be something that acts as a generator for a lazy list? Really? And you'd get that faster than guessing what 'gather' might mean? Do you think the same is true of someone without a CS degree and/or a rather advanced background? > >> however "gather" is much easier to say in polite company, > >> and is therefore a better name to use at the language level. We should not have the implementation and the HLLs use utterly different terminology for the same concept (unless every HLL uses different terminology and they all suck) -- that will just confuse contributors who don't do full time core work. It is certainly proper for the core and the HLLs to use different terminology for things that are similar but different, but in this case we're talking about the implementation of the HLL concept -- it should use the same terminology. Of course, I'm fine with using slightly more verbosity in the core, because it will be more rarely looked at and therefore needs to optimize more for clarity than stroke reduction. > > 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. Along the same lines, how about one of the following pairs? * .CONTROL_GENERATOR_GATHER and .CONTROL_GENERATOR_TAKE * .CONTROL_GENERATOR_SINK and .CONTROL_GENERATOR_SOURCE * .CONTROL_GATHER_SINK and .CONTROL_GATHER_SOURCE * .CONTROL_GATHER_LIST and .CONTROL_YIELD_LIST_ELEMENT(S) * .CONTROL_LIST_GATHER and .CONTROL_LIST_YIELD * .CONTROL_LAZY_GATHER and .CONTROL_LAZY_YIELD * .CONTROL_LAZY_LIST_GATHER and .CONTROL_LAZY_LIST_YIELD (Or something similar; my naming fu is off today.) -'f
