Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
jerry gay wrote: Patrick R. Michaud wrote: 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 wouldn't mind. I mean, various languages will certainly have a type called Hash, but that doesn't mean the core Parrot type needs to be. And really, it would fit in better with our general PMC naming scheme, and might open up the door for AssociativeStringArray, AssociativeIntegerArray, and AssociativeBooleanArray. 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. H... yeah, I like that idea. Especially since 'break' and 'continue' mean different things in different languages and different contexts (like 'break' and 'continue' in gdb, for example). Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: It's also a little unique that the take/yield can happen from called subs deep within the coroutine, and doesn't have to occur within the coroutine itself. That's a general characteristic of all the control exceptions: they can be caught by any outer dynamic scope, not just the immediate surrounding dynamic scope. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: What's the language-agnostic term for this, then? Well, 'gather' is basically a clever use of a coroutine, and 'take' is basically a 'yield'. But, what's unique about the construct is that it aggregates the results. So, 'gather' is an aggregating coroutine and 'take' is an aggregating yield. To allow for a distinction in the control exception types, call it 'CONTROL_YIELD_AGGREGATE'. 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. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 09:23:50AM +0200, Allison Randal wrote: What's the language-agnostic term for this, then? Well, 'gather' is basically a clever use of a coroutine, and 'take' is basically a 'yield'. But, what's unique about the construct is that it aggregates the results. So, 'gather' is an aggregating coroutine and 'take' is an aggregating yield. It's also a little unique that the take/yield can happen from called subs deep within the coroutine, and doesn't have to occur within the coroutine itself. To allow for a distinction in the control exception types, call it 'CONTROL_YIELD_AGGREGATE'. 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'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. Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
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. -'f
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
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's the difference between gather and aggregating coroutine? lipstick. but seriously, folks, what some refer to as traits, perl 6 calls roles. what some refer to as associative arrays, perl calls hashes. but aren't hashes that funny key on your phone you type after you've entered your credit card info? oh, right, that's pound. huh? i thought that's an outdated form of currency. let's call it octothorpe. wait, what? you store your dispatch table in an octothorpe? we need to be precise in naming constructs, rather than using common names. scientists call a chanterelle mushroom by its proper name, Cantharellus cibarius. 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. 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. ~jerry
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
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
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
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
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
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
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) Absolutely. But for that it shouldn't be called CONTROL_TAKE, because that's meaningless outside Perl 6. So, I think we can't always say oh, only one dynamic language needs this feature so it shouldn't be global -- we need to also consider those dynamic-languages-yet-to-be-written because Parrot is such an incredible platform for creating them. Yes, that's not the principle. The principle is that global things should be language-agnostic, and not use terminology that's confusing to all the other languages. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Not long ago, Patrick R. Michaud proclaimed... I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) I plan to add support for gather/take to cardinal. While we're discussing it, though, it might be fun to add it to lolcode, for purposes of flashy inter-hll demos.
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Wed, Sep 17, 2008 at 10:57:31AM +0200, Allison Randal wrote: Patrick R. Michaud wrote: I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) Absolutely. But for that it shouldn't be called CONTROL_TAKE, because that's meaningless outside Perl 6. [...] The principle is that global things should be language-agnostic, and not use terminology that's confusing to all the other languages. What's the language-agnostic term for this, then? Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote: +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. It might be a bit misleading, because it doesn't actually correspond to a .yield (and thus I can envision CONTROL_YIELD as yet another exception type). I'm still brainstorming ways to get the gather/take semantics we need by using Parrot's .yield, but so far I haven't come up with a good way to do it. Eventually we'll need to stop defining exception types as a global enum, and let individual languages define their own. EXCEPTION_TAKE really doesn't make sense for anything other than Perl 6. Not today, but someday. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Tue, Sep 16, 2008 at 11:45:17PM +0200, Allison Randal wrote: Patrick R. Michaud wrote: What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. It might be a bit misleading, because it doesn't actually correspond to a .yield (and thus I can envision CONTROL_YIELD as yet another exception type). Eventually we'll need to stop defining exception types as a global enum, and let individual languages define their own. EXCEPTION_TAKE really doesn't make sense for anything other than Perl 6. Not today, but someday. I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) In particular, having gather/take readily available may make it easier to implement many internal functions and libraries, even if gather/take itself isn't directly exposed at the HLL layer. Similar arguments probably hold for other core features of Parrot. So, I think we can't always say oh, only one dynamic language needs this feature so it shouldn't be global -- we need to also consider those dynamic-languages-yet-to-be-written because Parrot is such an incredible platform for creating them. Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Sat, Sep 13, 2008 at 12:05 AM, [EMAIL PROTECTED] wrote: Author: tene Date: Fri Sep 12 21:05:37 2008 New Revision: 31049 Modified: trunk/include/parrot/exceptions.h trunk/languages/perl6/src/builtins/control.pir trunk/languages/perl6/src/parser/actions.pm trunk/languages/perl6/t/spectest_regression.data Log: [rakudo] * First draft of gather/take Modified: trunk/include/parrot/exceptions.h == --- trunk/include/parrot/exceptions.h (original) +++ trunk/include/parrot/exceptions.h Fri Sep 12 21:05:37 2008 @@ -87,7 +87,8 @@ CONTROL_OK, CONTROL_BREAK, CONTROL_CONTINUE, -CONTROL_ERROR +CONTROL_ERROR, +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? -- Will Coke Coleda
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Sat, Sep 13, 2008 at 09:09:58AM -0400, Will Coleda wrote: --- trunk/include/parrot/exceptions.h (original) +++ trunk/include/parrot/exceptions.h Fri Sep 12 21:05:37 2008 @@ -87,7 +87,8 @@ CONTROL_OK, CONTROL_BREAK, CONTROL_CONTINUE, -CONTROL_ERROR +CONTROL_ERROR, +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Speaking of exception type names, I have a question about CONTROL_BREAK and CONTROL_CONTINUE. An interesting artifact of Perl 6 is that it has break and continue keywords, but they don't apply to looping constructs the way that break and continue do in other languages. (The Perl analogues of C's break and continue are last and next.) I know that we're explicitly not trying to make Parrot directly follow Perl's models, but perhaps the rationale for having Perl (both 5 and 6) choose next/last instead of the traditional break/continue might be applicable to Parrot nomenclature as well. So, perhaps CONTROL_BREAK and CONTROL_CONTINUE should really be CONTROL_NEXT and CONTROL_LAST (and we may also want a CONTROL_REDO in there somewhere also). Pm
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Sat, Sep 13, 2008 at 10:52 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Sat, Sep 13, 2008 at 09:09:58AM -0400, Will Coleda wrote: --- trunk/include/parrot/exceptions.h (original) +++ trunk/include/parrot/exceptions.h Fri Sep 12 21:05:37 2008 @@ -87,7 +87,8 @@ CONTROL_OK, CONTROL_BREAK, CONTROL_CONTINUE, -CONTROL_ERROR +CONTROL_ERROR, +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. Speaking of exception type names, I have a question about CONTROL_BREAK and CONTROL_CONTINUE. An interesting artifact of Perl 6 is that it has break and continue keywords, but they don't apply to looping constructs the way that break and continue do in other languages. (The Perl analogues of C's break and continue are last and next.) I know that we're explicitly not trying to make Parrot directly follow Perl's models, but perhaps the rationale for having Perl (both 5 and 6) choose next/last instead of the traditional break/continue might be applicable to Parrot nomenclature as well. So, perhaps CONTROL_BREAK and CONTROL_CONTINUE should really be CONTROL_NEXT and CONTROL_LAST ... I was going to argue about this, but soon realized it didn't matter, as either of these sets has decipherable names. Just make sure all the uses of the old names are updated when this changes. . (and we may also want a CONTROL_REDO in there somewhere also). Pm Ok. (We should have a plan in the HLL docs for how to deal with control exceptions that your language doesn't speak natively.) -- Will Coke Coleda
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote: +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. It might be a bit misleading, because it doesn't actually correspond to a .yield (and thus I can envision CONTROL_YIELD as yet another exception type). I'm still brainstorming ways to get the gather/take semantics we need by using Parrot's .yield, but so far I haven't come up with a good way to do it. Pm
