On Thu, 24 Jun 2004 10:55:26 -0700, Larry Wall [EMAIL PROTECTED] wrote:
Well, any operator or function that knows how to call a closure can
function as a short-circuit operator. The built-in short-circuit
operators are a bit special insofar as they're a kind of macro that
treats the right side
Alexey Trofimenko writes:
On Thu, 24 Jun 2004 10:55:26 -0700, Larry Wall [EMAIL PROTECTED] wrote:
Well, any operator or function that knows how to call a closure can
function as a short-circuit operator. The built-in short-circuit
operators are a bit special insofar as they're a kind of
to create user-defined operators. I had tried sml (a functional
language) and despite its being really simple if compared to Perl, it
provided this functionality...
Michele
--
Dante, _The Inferno_, in particular the line about, ``Abandon all hope ye who
enter here.''
- William F. Adams
| to specify a (finite number of) argument(s) on the left of functions, thus
| allowing to create user-defined operators. I had tried sml (a functional
| language) and despite its being really simple if compared to Perl, it
| provided this functionality...
If SML is anything like Haskell, user-defined
a (finite number of) argument(s) on the left of functions, thus
: allowing to create user-defined operators. I had tried sml (a functional
: language) and despite its being really simple if compared to Perl, it
: provided this functionality...
Yes, this is already provided for with infix/postfix
of
: | function prototyping (signatures?), I wonder wether it will be possible
: | to specify a (finite number of) argument(s) on the left of functions, thus
: | allowing to create user-defined operators. I had tried sml (a functional
: | language) and despite its being really simple if compared to Perl
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
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 function
--- 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
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
--- 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; $b {
$j +=
--- 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?
for
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
--- 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 that
indicates
that the parameter is not
- 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 [EMAIL PROTECTED] wrote:
Dave Whipp wrote:
Joe
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
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!
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 {...}
Alternatively, there might be a new parameter type that indicates that the
parameter is not evaluated
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:
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 would be
20 matches
Mail list logo
