On Fri, Oct 07, 2005 at 10:28:13 -0400, Austin Hastings wrote:
> But the point is that "resuming from an exception" (or
> appearing to) is not bound to "implemented with continuations".
What's the point?
Continuations are good for exactly this purpose. Parrot already
supports them. I see absolut
Yuval Kogman wrote:
>On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote:
>
>
>>Yuval Kogman wrote:
>>
>>
>>
>>>Stylistically I would tend to disagree, actually. I think it's cleaner to
>>>use exception handling for this.
>>>
>>>Also, this implies that you know that the errors are
HaloO
Yuval Kogman wrote:
We have:
die: throw immediately
fail: return an unthrown exception, which will be thrown
depending on whether our caller, and their caller - every scope
into which this value propagates - is using fatal.
This is enough for normal excep
[EMAIL PROTECTED] wrote:
I'm not bashing your idea, because I think it has uses. But I'll
point out that all of these can be easily accompilshed by writing a
wrapper for open(). That would be the usual way to abstract this kind
of thing.
My take on this: resumable exceptions break encaps
On Fri, Oct 07, 2005 at 05:23:55 +0100, Piers Cawley wrote:
> "Peter Haworth" <[EMAIL PROTECTED]> writes:
>
> > On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
> >> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> >> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> >> > > Pi
On Fri, Oct 07, 2005 at 02:31:12 -0400, Austin Hastings wrote:
> Yuval Kogman wrote:
>
> >On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
> >
> >
> >>On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>when i can't open a file and $! tells me why i couldn't
Yuval Kogman wrote:
>On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
>
>
>>On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>>
>>
>>>when i can't open a file and $! tells me why i couldn't open, i
>>>can resume with an alternative handle that is supposed to be t
"Peter Haworth" <[EMAIL PROTECTED]> writes:
> On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
>> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
>> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
>> > > Piers Cawley wrote:
>> > > >>Exactly which exception is continued?
>> > >
On Thu, Oct 06, 2005 at 14:27:30 -0600, Luke Palmer wrote:
> On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> > when i can't open a file and $! tells me why i couldn't open, i
> > can resume with an alternative handle that is supposed to be the
> > same
> >
> >
On 10/6/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> when i can't open a file and $! tells me why i couldn't open, i
> can resume with an alternative handle that is supposed to be the
> same
>
> when I can't reach a host I ask a user if they want to wait any
>
On Thu, Oct 06, 2005 at 18:11:38 +0100, Peter Haworth wrote:
> The highest level exception is the only one a caller has any right to deal
> with, but even then it doesn't really know what will happen if it resumes
> some random continuation attached to the exception.
But then we gain nothing
> >
On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote:
> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > > Piers Cawley wrote:
> > > >>Exactly which exception is continued?
> > > > The bottommost one. If you want to return to somew
On Wed, Oct 05, 2005 at 13:41:37 -0700, Dave Whipp wrote:
> Reading this thread, I find myself wondering how a resumable exception
> differs
> from a dynamically scropted function. Imagine this code:
This is sort of like what I mean, except that there is no
encapsulation breakage, since the inte
On Wed, Oct 05, 2005 at 13:00:55 -0600, Luke Palmer wrote:
> I don't think it was a "how is this possible", but more of a "what
> business does it have?". And as far as I gathered, they're saying
> pretty much what you've been saying, but in a different way. It's
> about the continuation boundar
Luke Palmer wrote:
Of course, exactly how this "public interface" is declared is quite undefined.
Reading this thread, I find myself wondering how a resumable exception
differs from a dynamically scropted function. Imagine this code:
sub FileNotWriteable( Str $filename ) {
die "can't write
On 10/5/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > > Whow, how does a higher level exception catcher *in general* know
> > > what type it should return and how to construct it? The
On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote:
> On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> > Piers Cawley wrote:
> > >>Exactly which exception is continued?
> > > The bottommost one. If you want to return to somewhere up its call
> > > chain, do:
> > >
> > > $!.caller(n).cont
On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote:
> Piers Cawley wrote:
> >>Exactly which exception is continued?
> > The bottommost one. If you want to return to somewhere up its call
> > chain, do:
> >
> > $!.caller(n).continue(42)
>
> Whow, how does a higher level exception catcher *in general* k
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
> errorMess
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
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 t
On Fri, Sep 30, 2005 at 17:09:23 +0200, TSa wrote:
> And it is the type system that guaranties the availability
> of the required information e.g. in $!.
$! is polymorphic.
Since CATCH is a topcializer, and you use when blocks to case over
$!, you can check to see if it has the metadata you want
On Fri, Sep 30, 2005 at 18:02:46 +0200, TSa wrote:
> I knew that the statement would emotionalize. Sorry to all who don't
> like it an this list. But somehow I found it describes the impression
> on the handling side somewhat. And I thought it illustrates that exceptions
> shouldn't be considered j
HaloO Piers,
you wrote:
TSa <[EMAIL PROTECTED]> writes:
BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
I knew that the statement would emotionalize. Sorry to all who
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
maint
TSa <[EMAIL PROTECTED]> writes:
> BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
CATCH Exception { say "Why do you hate freedom?" }
--
Piers Cawley <[EMAIL PROTECTED]>
h
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: ($lhs is delayed, $rhs i
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::Wa
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 calculat
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
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, I'
On Wed, Sep 28, 2005 at 09:49:11 -0700, Larry Wall wrote:
> I'd like to add a little more. The context of the original throw
> probably knows best whether it's even possible or sensical to
> continue, so it should be optional whether the exception contains a
> resume continuation. The presence of
I'd like to add a little more. The context of the original throw
probably knows best whether it's even possible or sensical to
continue, so it should be optional whether the exception contains a
resume continuation. The presence of the continuation signals that
the inner code would *like* to cont
Nigel Hamilton schreef:
> From the point of view of the operating system a program is a nasty
> exception to its normal running environment - your whole program is a
> kind of big exception!
As if a real OS really likes to run idle most of the time.
;)
> Like someone intruding on a conversation
On Tue, Sep 27, 2005 at 07:29:48 +0100, Nigel Hamilton wrote:
> >And handling user errors in a GUI application is a task for event handling,
> >*not* exception handling. I agree that both mechanisms share large parts
> >of the infra-structure supporting them. But I make a strong conceptual
> >dist
And handling user errors in a GUI application is a task for event handling,
*not* exception handling. I agree that both mechanisms share large parts
of the infra-structure supporting them. But I make a strong conceptual
distinction between them.
Which leads to the question, does Perl6 have or n
On Mon, Sep 26, 2005 at 17:40:52 +0100, Piers Cawley wrote:
> Luke Palmer <[EMAIL PROTECTED]> writes:
>
> > On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> >> I propose a new model - each exception has a continuation that
> >> allows it to be unfatalized.
> >
> > I think we've already talked
TSa <[EMAIL PROTECTED]> writes:
> HaloO,
>
> Piers Cawley wrote:
>>>Exactly which exception is continued?
>> The bottommost one. If you want to return to somewhere up its call chain, do:
>> $!.caller(n).continue(42)
>
> Whow, how does a higher level exception catcher *in general* know
> what typ
HaloO,
Piers Cawley wrote:
Exactly which exception is continued?
The bottommost one. If you want to return to somewhere up its call chain, do:
$!.caller(n).continue(42)
Whow, how does a higher level exception catcher *in general* know
what type it should return and how to construct it. The
Luke Palmer <[EMAIL PROTECTED]> writes:
> On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>> I propose a new model - each exception has a continuation that
>> allows it to be unfatalized.
>
> I think we've already talked about something like this. But in the
> presence of "use fatal", it make
On Sun, Sep 25, 2005 at 11:32:54 -0600, Luke Palmer wrote:
> Exactly which exception is continued?
...
> This comes up again with open(). So it's somewhere in between.
> Where?
For the open() example I don't have a solution but I know in what
direction to throw it: the same thing that makes croa
On 9/25/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> [...]
> Exactly which exception is continued?
> [...]
Named restarts in Common Lisp appear to try to solve a related
problem, if I'm skimming this thread correctly. :-) (see [1]).
Michael
[1]
http://www.supelec.fr/docs/cltl/clm/node312.html#SE
On 9/25/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
> I propose a new model - each exception has a continuation that
> allows it to be unfatalized.
I think we've already talked about something like this. But in the
presence of "use fatal", it makes a lot more sense.
Something comes to mind:
To ease the understanding of exactly how this might work, assume
that perl 6 is really all continuation passing style under the
surface (parrot is ;-).
use fatal;
my $x = do_bar();
do_foo();
sub do_bar {
fail "bah";
}
The way CPS works is r
On Sun, Sep 25, 2005 at 18:11:22 +0300, Yuval Kogman wrote:
> In order to support continuable exception generators, here is a
> style guide for exception values, and an observation on what
> exceptions should support at the language level:
And more...
* Exception strings are for humans
Humans ne
In order to support continuable exception generators, here is a
style guide for exception values, and an observation on what
exceptions should support at the language level:
* Exceptions should preserve data
All exceptions should contain as much of the original data that
caused them...
With Luke
46 matches
Mail list logo
