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.
> a related point: wherever these constructs are defined, they need to
> be documented. you may think "CONTROL_RETURN" is obviously for
> "return" statements, but many will find it quite strange that "return"
> is an Exception at all.
Agreed that we should document them all somewhere. I vote that we
do it in the Exceptions PDD. :-P
Pm
