HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 09:49:11 -0700, Larry Wall wrote:
But thinking about optional continuations, another thing occured
to me. It's always bugged me that warnings were something different
from exceptions, and now I think we can unify them, if we say that
Yes,
Hi!
On Thu, Sep 29, 2005 at 10:49:40 +0200, TSa wrote:
BTW, I would call *intentional* exceptions terrorism.
Then I would call terrorism non linear control flow ;-)
In that case Afghanistan might be harboring computer scientists that
really like CPS, and bush is Java ;-)
In lack of a better
At 11:46 AM -0500 9/28/05, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that use fatal be on by default,
I totally, TOTALLY, agree with this.
EVERY built-in function and operator that talks to
I'd like to ammend, and perhaps formalize with some definitions from
my dictionary, which ships with OSX:
error - a mistake... the state or condition of being wrong in
conduct or judgement... technical - a measure of the estimated
difference between the observed or
HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something I've been
thinking for a while. In short, I propose that use fatal be on by default,
and
that err be turned into syntactic sugar for a
On Thu, Sep 29, 2005 at 12:53:51 +0200, TSa wrote:
I don't like it at all. I fear, that we mix two orthogonal concepts
just because it is convenient.
just because it is convenient is precicely why I like it =)
To me the statement
return 42; # 1
has to orthogonal meanings:
1)
TSa schreef:
Yes, I'm also all for unifying the concepts. But please
don't let us call it exception. Exception should be a
termination oriented (sub)concept. Some kind of scoped giving
up. [...]
In lack of a better word I use Event and we get
Event::Exception, Event::Control, Event::Warn
Hi,
TSa wrote:
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
thinking for a while. In short, I propose that use fatal be on by
default, and that err be turned into syntactic sugar for a very
small try/CATCH block.
I like it a lot. It gives the
On 29/09/05, Ingo Blechschmidt [EMAIL PROTECTED] wrote:
* try { foo() } err next will next even if foo() did not throw
an exception, but returned undef. But I don't think that's a problem
in most cases. One can always do:
try { foo(); 1 }
I think that's a flag that it's not a great
Luke Palmer wrote:
Joked? Every other language that has pattern matching signatures that
I know of (that is, ML family and Prolog) uses _. Why should we break
that? IMO, it's immediately obvious what it means.
Something tells me that in signature unification, undef means this
has to be
Imagine you're writing an implementation of the unix uniq function:
my $prev;
for grep {defined} @in - $x {
print $x unless defined $prev $x eq $prev;
$prev = $x;
}
This feels clumsy. $prev seems to get in the way of what I'm trying to
say. Could we imbue optional
TSa wrote:
HaloO,
Yuval Kogman wrote:
On Wed, Sep 28, 2005 at 11:46:37 -0500, Adam D. Lopresto wrote:
The recent thread on Expectuations brought back to mind something
I've been
thinking for a while. In short, I propose that use fatal be on by
default, and
that err be turned into
Dave Whipp wrote:
Imagine you're writing an implementation of the unix uniq function:
my $prev;
for grep {defined} @in - $x {
print $x unless defined $prev $x eq $prev;
$prev = $x;
}
This feels clumsy. $prev seems to get in the way of what I'm trying to
say.
On 9/29/05, Dave Whipp [EMAIL PROTECTED] wrote:
for grep {defined} @in - $item, ?$next {
print $item unless defined $next $item eq $next;
}
This is an interesting idea. Perhaps for (and map) shift the
minimum arity of the block from the given list and bind the maximum
arity. Of
Luke Palmer wrote:
On 9/29/05, Dave Whipp [EMAIL PROTECTED] wrote:
for grep {defined} @in - $item, ?$next {
print $item unless defined $next $item eq $next;
}
This is an interesting idea. Perhaps for (and map) shift the
minimum arity of the block from the given list
On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
You already know that err is the low-precedence version of //, right?
What replaces that? I like default or defaults myself,
Yes, he proposed 'dor'.
As I see it err is like this:
sub infix:err ($lhs is delayed, $rhs is
Austin~
On 9/29/05, Austin Hastings [EMAIL PROTECTED] wrote:
Plus it's hard to talk about backwards. If you say
for @l - ?$prev, $curr, ?$next {...}
what happens when you have two items in the list? I think we're best off
using signature rules: optional stuff comes last.
I disagree, I
On 9/29/05, Austin Hastings [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
This is an interesting idea. Perhaps for (and map) shift the
minimum arity of the block from the given list and bind the maximum
arity. Of course, the minimum arity has to be = 1 lest an infinite
loop occur.
Or not.
Matt Fowles wrote:
Austin~
On 9/29/05, Austin Hastings [EMAIL PROTECTED] wrote:
Plus it's hard to talk about backwards. If you say
for @l - ?$prev, $curr, ?$next {...}
what happens when you have two items in the list? I think we're best off
using signature rules: optional stuff comes
On 9/29/05, Austin Hastings [EMAIL PROTECTED] wrote:
Matt Fowles wrote:
for (1, 2) - ?$prev, $cur, ?$next {
say $prev - $cur if $prev;
say $cur;
say $cur - $next if $next;
say next;
}
[...]
I assume so because it's the only execution path that seems to work. But
that
20 matches
Mail list logo
