Michael Lazzaro asked:
(@foo, @bar) := @a
. grep { $_ 0}
. sort { $^b = $^b }
. part [/foo/, /bar/];
Hmm. Does operator precedence allow that?
I don't think the method-call syntax allows it. I think methods
need their parens. So we need:
(@foo, @bar) := @a
. grep( {
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
--
ralph
[EMAIL PROTECTED] (Damian Conway) writes:
I don't think the method-call syntax allows it. I think methods
need their parens. So we need:
(@foo, @bar) := @a
. grep( { $_ 0} )
. sort( { $^b = $^b } )
. part( [/foo/, /bar/] );
*Why* do methods need their parens?
On 12/10/2002 4:54 AM, Me wrote:
How would one most nicely code what I'll call
a lazy pipeline, such that the first result
from the final element of the pipeline can
appear as soon as the first result has been
processed from the intervening elements?
I belive the short answer is make sure all
On 10 Dec 2002 11:41:23 +, Simon Cozens wrote:
[EMAIL PROTECTED] (Damian Conway) writes:
I don't think the method-call syntax allows it. I think methods
need their parens. So we need:
(@foo, @bar) := @a
. grep( { $_ 0} )
. sort( { $^b = $^b } )
.
[EMAIL PROTECTED] (Peter Haworth) writes:
To know whether the method takes a block, you need to know how it's been
declared. In other words, the type of @a needs to be known to find grep's
declaration.
Well, that's what always happens on a method call.
In turn, grep must specify its return
On 10 Dec 2002 15:34:11 +, Simon Cozens wrote:
[EMAIL PROTECTED] (Peter Haworth) writes:
To know whether the method takes a block, you need to know how it's been
declared. In other words, the type of @a needs to be known to find
grep's declaration.
Well, that's what always happens on
[EMAIL PROTECTED] (Peter Haworth) writes:
Fair enough; that simplifies things somewhat. However, you can't tell how
many arguments they take. How do you parse this without the programmer
specifying a great deal more than they're used to in Perl 5?
$foo.bar $baz,$qux
I see no block here.
On 10 Dec 2002 17:25:34 +, Simon Cozens wrote:
[EMAIL PROTECTED] (Peter Haworth) writes:
Fair enough; that simplifies things somewhat. However, you can't tell
how many arguments they take. How do you parse this without the
programmer specifying a great deal more than they're used to in
On Tue, Dec 10, 2002 at 01:53:28PM +1100, Damian Conway wrote:
And in those rare cases where you really do need partial caching, the
simplest solution is to split the partially cached subroutine into a
fully cached sub and an uncached sub:
sub days_in_month(Str $month, Int $year)
{
On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
--- Adam Turoff [EMAIL PROTECTED] wrote:
It doesn't matter whether some of the values are cheap lookups
while other values are complex calculations. Once a cached sub
is called with a set of parameter values, the return value
On Mon, Dec 09, 2002 at 01:58:11PM -0800, Austin Hastings wrote:
--- Adam Turoff [EMAIL PROTECTED] wrote:
I think you're trying to overoptimize something here. I can't see
a benefit to caching only sometimes. If there is, then you probably
want to implement a more sophisticated cache
On Mon, Dec 09, 2002 at 02:20:01PM -0800, Austin Hastings wrote:
--- Paul Johnson [EMAIL PROTECTED] wrote:
How about the same way as one would do it now? Presumably we won't
all
forget how to program when Perl 6 comes out.
I think you've missed the point. The original poster (Smylers)
I was reading the Partially Memorized Functions thread, and the thought
came to mind that what we really need, is to define a different
implementation of the method for a specific value of the arg. Something
like:
sub days_in_month( Str $month, Int $year )
{
...
}
sub days_in_month( Str $month
On Tue, Dec 10, 2002 at 11:37:58AM -0800, David Whipp wrote:
I was reading the Partially Memorized Functions thread, and the thought
came to mind that what we really need, is to define a different
implementation of the method for a specific value of the arg. Something
like:
sub
Peter Haworth:
# @b = @a.grep { /\S/ }, $c;
#
# how does the compiler know whether $c is an argument to grep,
# or another element to be assigned to @b?
The same way it does when it sees a normal sub?
I know, late binding and all that. But when you think about it, a lot
can be done to
On Tue, Dec 10, 2002 at 01:02:18PM -0800, Brent Dax wrote:
Peter Haworth:
# @b = @a.grep { /\S/ }, $c;
#
# how does the compiler know whether $c is an argument to grep,
# or another element to be assigned to @b?
The same way it does when it sees a normal sub?
I know, late binding
Michael G Schwern wrote:
On Mon, Dec 09, 2002 at 08:36:20PM -, Smylers wrote:
That way a function could decide to cache some return values but not
all of them.
The example above is a classic example of premature optimization.
There's nothing which ways the cache would be
On Tue, Dec 10, 2002 at 10:46:07PM -, Smylers wrote:
The example above is a classic example of premature optimization.
There's nothing which ways the cache would be counter-productive for
simple calculations since the caching logic is nearly as simple.
OK. There was something on
Simon Cozens asked:
*Why* do methods need their parens?
Because calls to them are not resolved until run-time and because methods
can be overloaded by signature, so we can't tell at parse time what the
parameter list of the called method will be (i.e. where it will end),
so we can't determine
Adam Turoff wrote:
sub days_in_month(Str $month, Int $year)
{
$month = lc $month;
if $month eq 'feb'
{
my sub feb_days (Int $year) is cached {
my $leap = $year % 4 == 0
($year % 100 != 0 || $year % 400 == 0);
return $leap ? 29 : 28;
}
return
David Whipp wrote:
I was reading the Partially Memorized Functions thread, and the thought
came to mind that what we really need, is to define a different
implementation of the method for a specific value of the arg. Something
like:
sub days_in_month( Str $month is value{ rx:i/feb[ruary]?/ },
Damian Conway wrote:
For that reason, even if we can solve this puzzle, it might be far kinder
just to enforce parens.
I might be weird, but when I use parens to clarify code in Perl, I
like to use the Lisp convention:
(method $object args)
Hopefully that will still work even if Perl 6
RM == Rich Morin [EMAIL PROTECTED] writes:
RM On occasion, I have found it useful to cobble up a little language
RM that allows me to generate a list of items, using a wild-card or some
RM other syntax, as:
RMfoo[0-9][0-9] yields foo00, foo01, ...
RM I'm wondering whether Perl
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote:
On occasion, I have found it useful to cobble up a little language
that allows me to generate a list of items, using a wild-card or some
other syntax, as:
foo[0-9][0-9] yields foo00, foo01, ...
I'm wondering whether Perl
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Tue, 10 Dec 2002 21:07:34 -0500
From: Adam Turoff [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Content-Disposition: inline
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Date: Tue, 10 Dec 2002 15:38:58 -0800
From: Rich Morin [EMAIL PROTECTED]
X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
On occasion, I have found it useful to cobble up a little language
that allows me to generate a list of
LP == Luke Palmer [EMAIL PROTECTED] writes:
LP Why use regexen when you can just use junctions?
LP my $foos = 'foo' ~ any(0..9) ~ any(0..9);
should that be @foos or will it make an anon list of the foos and store
the ref?
LP We have a Ipowerful language on our hands, people.
i know
LP == Luke Palmer [EMAIL PROTECTED] writes:
LP my $foos = 'foo' ~ any(0..9) ~ any(0..9);
should that be @foos or will it make an anon list of the foos and store
the ref?
LP Actually $foos will be a junction. You could use Cstates to get
LP each state out of the junction in an
29 matches
Mail list logo
