On Wed, Sep 28, 2005 at 11:46:37AM -0500, Adam D. Lopresto wrote:
[2] I've actually seen data lost due to this. When drive space is very
limited
(due to, for instance, a user quota) it's often possible to open a new file
(since
there's some space left), but the close fails since too much
Yuval Kogman wrote:
On Thu, Sep 29, 2005 at 13:52:54 -0400, Austin Hastings wrote:
[Bunches of stuff elided.]
A million years ago, $Larry pointed out that when we were able to use
'is just a' classifications on P6 concepts, it indicated that we were
making good forward progress. In that
TSa wrote:
The view I believe Yuval is harboring is the one examplified
in movies like The Matrix or The 13th Floor and that underlies
the holodeck of the Enterprise: you can leave the intrinsic
causality of the running program and inspect it. Usually that
is called debugging. But this
On Sat, Oct 01, 2005 at 05:57:54 -0400, Austin Hastings wrote:
Internally, it may be the same. But with exceptions, it's implemented by
someone other than the victim, and leveraged by all. That's the kind of
abstraction I'm looking for. My problem with the whole notion of Either
errorMessage
HaloO,
Yuval Kogman wrote:
The try/catch mechanism is not like the haskell way, since it is
purposefully ad-hoc. It serves to fix a case by case basis of out
of bounds values. Haskell forbids out of bound values, but in most
programming languages we have them to make things simpler for the
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
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)
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
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
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
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 very small try/CATCH block.
Basically, my observation is that no-one consistently checks the
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 very small try/CATCH block.
14 matches
Mail list logo
