On Tue, Apr 01, 2003 at 08:26:38PM -0500, Joe Gottman wrote:
:Is there any way to write a user-defined operator so that it
: short-circuits, like && and || ? This might be function trait, for
: instance,
:
: sub infix:!! ($lhs, $rhs) is short_circuit {...}
Honestly, you guys. You make thi
Joe Gottman wrote:
There are two reasonable semantics for deferred parameters:
1) lazy evaluation with caching, where the evaluation of the
actual expression in the call is deferred until the sub
actauly makes use of it and the result is then cached and
reused as necessary. Any side effects happ
- Original Message -
From: "Luke Palmer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 03, 2003 6:39 PM
Subject: Re: Short-circuiting user-defined operators
> > Paul wrote:
> > > --- Austin Hastings
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Paul wrote:
> > > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > >
> > >>Dave Whipp wrote:
> > >>
> > >>>Joe Gottman wrote:
> > >
> > >
> > > Getting deep -- sorry. :)
> > >
> > >
> > Alternatively, there might be a new parameter type tha
> Paul wrote:
> > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> >
> >>Dave Whipp wrote:
> >>
> >>>Joe Gottman wrote:
> >
> >
> > Getting deep -- sorry. :)
> >
> >
> Alternatively, there might be a new parameter type that indicates
> that the parameter is not evaluated immediately:
>
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> --- Paul <[EMAIL PROTECTED]> wrote:
> > > But what to do about matrix arithmetic and other simple
> > > threadable tasks?
> > > sub m_add(@a, @b) { my @result; my $i, $j; @result = @a;
> > > for @result -> $i {:is threaded # Thread this block
--- Paul <[EMAIL PROTECTED]> wrote:
> > But what to do about matrix arithmetic and other simple threadable
> > tasks?
> >
> > sub m_add(@a, @b) {
> > my @result;
> > my $i, $j;
> > @result = @a;
> > for @result -> $i {:is threaded # Thread this block?
> > for @result[$i]; @b -> $j;
Paul wrote:
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
Dave Whipp wrote:
Joe Gottman wrote:
Getting deep -- sorry. :)
Alternatively, there might be a new parameter type that indicates
that the parameter is not evaluated immediately:
sub infix:!! ($lsh, $rhs is deferred) {...}
If the sta
--- Austin Hastings <[EMAIL PROTECTED]> wrote:
> Dave Whipp wrote:
> > Joe Gottman wrote:
Getting deep -- sorry. :)
> > > Alternatively, there might be a new parameter type that indicates
> > > that the parameter is not evaluated immediately:
> > >
> > > sub infix:!! ($lsh, $rhs is deferred) {.
Dave Whipp wrote:
> Joe Gottman wrote:
>
> > Alternatively, there might be a new parameter type that indicates
> > that the parameter is not evaluated immediately:
> >
> > sub infix:!! ($lsh, $rhs is deferred) {...}
> A nice concept! So nice, in fact, that it would be a shame to limit
> it to
Is there any specific reason this was a reply to Michael Lazarro's "Re:
== vs. eq" dated Tue, 1 Apr 2003 16:30:00 -0800 ?
(What I mean is, PLEASE don't use reply when you're not replying at all)
--
Matthijs van Duin -- May the Forth be with you!
Dave Whipp writes:
> Another, very different, situation where laziness is good is to abstract
> fork/join situations:
>
>
>my $a is lazy_thread := expensive_fn1(...);
>my $b is lazy_thread := expensive_fn2(...);
>
>print $a + $b;
>
> In this scenario, each expensive evaluation woul
Joe Gottman wrote:
Alternatively, there might be a new parameter type that indicates that the
parameter is not evaluated immediately:
sub infix:!! ($lsh, $rhs is deferred) {...}
A nice concept! So nice, in fact, that it would be a shame to limit it
to function args. I could see myself writing:
13 matches
Mail list logo
