Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft

2008-08-30 Thread Bob Rogers
From: Allison Randal <[EMAIL PROTECTED]> Date: Sat, 30 Aug 2008 11:56:45 +0200 Bob Rogers wrote: > My sense of the usage on this list is that "multisub" means a MultiSub > PMC and a "multimethod" is what you add to the MultiSub when you define > a sub with the :multi keyword. A

Re: how much detail can I get from caller.want?

2008-08-30 Thread John M. Dlugosz
Have the sort function simply return a lazy list object. When the [4] is called on that object, it knows to do as much work as needed, and can leave the rest as lazy. --John Dave Whipp dave-at-whipp.name |Perl 6| wrote: Lets say I want to find the 5th smallest element in an array. I might wr

Re: [perl #47992] [RFE] 'parrot foo' automatically finds and invokes foo.pbc

2008-08-30 Thread Patrick R. Michaud
On Sat, Aug 30, 2008 at 07:45:08AM -0700, Allison Randal via RT wrote: > As mentioned in RT #49168, I'm in favor of a --language flag, > that selects the default PBC/PIR file to run, and passes all other > arguments to the ':main' sub in that file. It can also select default > paths based on the

Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds

2008-08-30 Thread Klaas-Jan Stol
On Sat, Aug 30, 2008 at 12:27 PM, Allison Randal <[EMAIL PROTECTED]> wrote: > Klaas-Jan Stol wrote: > >> > This is another one of those muddy cases in PIR where words conflict when they shouldn't. I can't think of any way that it's actually useful to have a variable named

Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds

2008-08-30 Thread Allison Randal
Klaas-Jan Stol wrote: This is another one of those muddy cases in PIR where words conflict when they shouldn't. I can't think of any way that it's actually useful to have a variable named 'add' prevent you from using the opcode 'add'. .. but of course, I don't want to exclude it. If it is rea

Re: [svn:parrot-pdd] r30620 - trunk/docs/pdds/draft

2008-08-30 Thread Allison Randal
Bob Rogers wrote: My sense of the usage on this list is that "multisub" means a MultiSub PMC and a "multimethod" is what you add to the MultiSub when you define a sub with the :multi keyword. Am I the only one who finds this a useful distinction? Oh, I see. No wonder this conversation has bee

Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19

2008-08-30 Thread Allison Randal
Klaas-Jan Stol wrote: On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal <[EMAIL PROTECTED]> wrote: Yes, it will be deprecated, or at least renamed. The C<.return> directive without parentheses is an old convention for passing a single return result, and must always be sandwiched between C<.beg

Fwd: [perl #58150] Doing split on the result of a slurped empty file results in a Null PMC Access in rakudo

2008-08-30 Thread Carl Mäsak
-- Forwarded message -- From: Ron Schmidt via RT <[EMAIL PROTECTED]> Date: Fri, Aug 29, 2008 at 10:14 PM Subject: [perl #58150] Doing split on the result of a slurped empty file results in a Null PMC Access in rakudo To: [EMAIL PROTECTED] > $ < empty ./perl6 -e 'say split("\n", $

Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19

2008-08-30 Thread Klaas-Jan Stol
On Sat, Aug 30, 2008 at 11:04 AM, Allison Randal <[EMAIL PROTECTED]> wrote: > Klaas-Jan Stol (via RT) wrote: > >> >> The parentheses surrounding the arguments are mandatory. Besides making >> sequence break more conspicuous, this is necessary to distinguish this >> syntax from other uses of the C<

Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19

2008-08-30 Thread Allison Randal
Klaas-Jan Stol (via RT) wrote: The parentheses surrounding the arguments are mandatory. Besides making sequence break more conspicuous, this is necessary to distinguish this syntax from other uses of the C<.return> directive that will be probably deprecated. The open issue of the 'probably dep