Re: RFC 80 (v1): Exception objects and classes for builtins
Redirected to perl6-language-flow. At 12:23 PM 8/11/00 +0100, Graham Barr wrote: On Thu, Aug 10, 2000 at 07:30:53PM -0700, Peter Scott wrote: If we're really talking about new keywords, we wouldn't need a ; at the end of the last block; it's only needed at the moment because eval is a function, not a keyword. I would vote for the keywords only because people are going to forget the ; otherwise. That maybe a reason to use `try' instead of `eval'. Another difference would be that try will rethrow uncaught error, eval does not. And of course a die in any catch block would throw an error to a try/eval block up the stack, after running the continue block. So adie; in the catch block would rethrow the same error. If we did use 'try', would we retire the block form of 'eval'? It could be confusing to have a keyword with almost identical but subtly different semantics to a function. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals
"NI" == Nick Ing-Simmons [EMAIL PROTECTED] writes: NI Uri Guttman [EMAIL PROTECTED] writes: i think we do because a thread can block on a mailbox while it can't on an array. NI Why not ? - I see no reason that a "shared" array could not have NI whatever-it-takes to allow blocking. then every op that could touch an array has to have code to support blocking. i think that would be a mess. and what is the definition of blocking on an array, is it empty? can i pop or shift it? how do you handle atomicity? how do you specify a non-blocking access (poll) on an array? mailboxes are defined to work fine with those requirements. a get on a mailbox will block until one item is retrieved and that is an atoamic operation. a get can be made non-blocking (polling) with a optional argument. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals
"DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Nope. The code that accessses the array needs to support it. Different DS animal entirely. The ops don't actually need to know. but still that is overhead code for all arrays and not just the mailbox ones. DS s/mailboxes/filehandles/; DS If we're talking a generic communication pipe between things, we DS should overload the filehandle. It's a nice construct that DS provides an ordered, serialized, blockable, pollable DS communications channel with well-defined behavior and a DS comfortable set of primitives to operate on it. pollable is a good thing. some mailbox designs are not pollable and some are. i like the idea of supporting polling then you can also have callbacks. but this does imply an implementation as semaphores and shared memory are not pollable. you would have to build this with pipes and filehandles. overlaying it on filehandles is another question. i would like to see a single operation which does an atomic lock, block, retrieve, unlock. we don't have that for filehandles. you could use a new method on that special handle (i like 'get') which has the desired semantics. i think making mailboxes in some form is a good idea. but they should be special objects (even if they are filehandles) with their own methods to support the desired semantics. uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting The Perl Books Page --- http://www.sysarch.com/cgi-bin/perl_books The Best Search Engine on the Net -- http://www.northernlight.com
Re: RFC 86 (v1) IPC Mailboxes for Threads and Signals
At 12:54 PM 8/11/00 -0400, Uri Guttman wrote: "DS" == Dan Sugalski [EMAIL PROTECTED] writes: DS Nope. The code that accessses the array needs to support it. Different DS animal entirely. The ops don't actually need to know. but still that is overhead code for all arrays and not just the mailbox ones. Nope. Just for the shared ones. DS s/mailboxes/filehandles/; DS If we're talking a generic communication pipe between things, we DS should overload the filehandle. It's a nice construct that DS provides an ordered, serialized, blockable, pollable DS communications channel with well-defined behavior and a DS comfortable set of primitives to operate on it. pollable is a good thing. some mailbox designs are not pollable and some are. i like the idea of supporting polling then you can also have callbacks. but this does imply an implementation as semaphores and shared memory are not pollable. you would have to build this with pipes and filehandles. So? Inter-thread communication is almost undoubtedly not going to be built with something as heavyweight as pipes, shm, or mailboxes, so I don't see their limitations as relevant here. Regardless, don't design to the limitations of one particular implementation method. We can work around their limits if need be. overlaying it on filehandles is another question. i would like to see a single operation which does an atomic lock, block, retrieve, unlock. we don't have that for filehandles. you could use a new method on that special handle (i like 'get') which has the desired semantics. So we enhance filehandles to make reads on them atomic. does an atomic read on the filehandle. NBD. i think making mailboxes in some form is a good idea. but they should be special objects (even if they are filehandles) with their own methods to support the desired semantics. Overload filehandles. They really are a good fit for what you're looking for. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 80 (v1): Exception objects and classes for builtins
I've moved this from perl6-language to perl6-language-flow.
Tony Olekshy wrote:
With the approach proposed in RFC 88 (Structured Exception
Handling Mechanism), you could write that as:
try {
} catch {
switch ($_[0]-name) {
case IO { ... }
case Socket { ... }
}
}
Graham Barr wrote:
the error are objects, so you need to allow for inheritance.
I was just trying to point out that RFC 88 uses try {} catch {}
instead of try {} otherwise {}, and that the current error comes
into the catch block via @_ (as in RFC 63), so one doesn't need a
"global".
Sometimes you want to collect all the catching into one clause (if,
say, there was lots of common code and little varying code). In
other cases, you want a seperate clause for each exception (if, say,
there is little common code, then the seperate clauses handle the
switch for you, which is more DWIM). That's why RFC 88 allows you
any combination of these operations, as in:
try {
}
except isa = "Foo" = catch { ... }
except isa = "Bar" = catch { ... }
except else = catch { ... }
Again, the differences between this and RFC 63's approach are, in
this case, only syntactic.
Yours, c, Tony Olekshy
Re: RFC 80 (v1): Exception objects and classes for builtins
I've moved this from perl6-language to perl6-language-flow.
Graham Barr wrote:
eval {
# fragile code
}
else { # catch ALL exceptions
switch ($@) {
case __-isa('IO') { ... }
case __-isa('Socket') { ... }
else { ... }
}
}
continue {
# code always executed (ie finally)
}
Chaim Frenkel wrote:
Nice.
Hmm. The eval was commented to indicate fragile code, which is
implied if the keyword try is used. The else was commented to
indicate a catch, instead of saying catch, and the continue was
commented to indicate a finally, instead of saying finally.
There does seem to me to be some benefit to the clarity of the
RFC 88 approach, which supports both:
try { }
except isa = 'IO' = catch { }
except isa = 'Socket' = catch { }
except else= catch { }
finally { }
and:
try { }
catch {
switch ($_[0]) {
case __-isa('IO') { ... }
case __-isa('Socket') { ... }
else { ... }
}
}
finally { }
Yours, c, Tony Olekshy
Re: RFC 80 (v1): Exception objects and classes for builtins
On Fri, Aug 11, 2000 at 09:36:32AM -0700, Peter Scott wrote:
Redirected to perl6-language-flow.
At 10:39 AM 8/11/00 -0400, John Porter wrote:
Piers Cawley wrote:
The (continue|always|finally|whatever) clause will *always* be
executed, even if one of the catch clauses does a die, so you can use
this to roll back the database transaction or whatever else was going
on and restore any invariants.
Which makes me think that it would be nice if the continue block could
come before the catch block(s):
establish_invariants();
try {
something_risky();
}
continue {
restore_invariants();
}
catch {
handle_error_assuming_invariants_restored();
}
The only point of using the continue block as you suggest is if there are
multiple catch blocks, otherwise you'd just do
Hm, my understanding is that the continue block would be run it there was
an error or not.
So with no errors you do
execute try
execute continue
but if there was an error
execute try
- die
execute continue
execute catch
Graham.
Re: RFC 80 (v1): Exception objects and classes for builtins
Peter Scott wrote:
John Porter wrote:
Which makes me think that it would be nice if the continue block
could come before the catch block(s).
I get where you're going with this but it breaks the paradigm too
much. Now you need a 'finally' block again.
Sometimes you want before, sometimes after, as in:
try {
open(*F, "foo") or throw "Can't open foo.";
print F ...;
}
finally { close F or throw "Can't close foo."; }
unwind { attempt_to_log_error_message($_[0]); }
which can also be written as:
try {
try {
open(*F, "foo") or throw "Can't open foo.";
print F ...;
}
finally { close F or throw "Can't close foo."; }
}
catch { attempt_to_log_error_message($_[0]); throw; }
The exception handling mechanism considered in RFC 88 has both
pre-finally and post-finally exception trapping clauses, named
catch and unwind.
The basic syntax considered in RFC 88 is:
try { ... throw ... } # try clause
except TEST = catch { ... }# 0 or more
catch { ... } # 0 or more
finally { ... } # 0 or more
unwind { ... }; # 0 or 1
The basic semantics are:
* The try clause is evaluated.
* Each catch clause is invoked, but only if an exception has
been raised since the beginning of the try statement, and
the catch clause's except TEST is true or is not given.
* Each finally clause is invoked whether or not an exception
has been raised since the beginning of the try statement.
* The unwind clause, if any, is invoked if an exception has
been raised since the beginning of the try statement, and
it has not been cleanly caught.
* After processing all clauses, try unwinds (dies) iff any
exception wasn't cleanly caught.
An exception is considered to be "cleanly caught" if it was in
the try clause, and it triggered a catch clause, and no catch
or finally clause raised an exception.
Yours, c, Tony Olekshy
