Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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 vein, let me propose that:
* Exception handling, and the whole try/catch thing, IS JUST An awkward
implementation of (late! binding) run-time return-type MMD.
Exception handling is just continuation passing style with sugar.
Have a look at haskell's either monad. It has two familiar keywords
- return and fail.
Every statement in a monadic action in haskell is sequenced by using
the monadic bind operator.
The implementation of =, the monadic bind operator, on the Either
type is one that first check to see if the left statement has
failed. If it does, it returns it. If it doesn't it returns the
evaluation of the right hand statement.
Essentially this is the same thing, just formalized into a type
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 resultingValue in Haskell is that we _could_ implement it
in perl as Exception|Somevalue in millions of p6 function signatures.
But I don't _want_ to. I want to say MyClass and have the IO subsystem
throw the exception right over my head to the top-level caller.
I guess that to me, exceptions are like aspects in they should be
handled orthogonally. Haskell's Either doesn't do that -- it encodes a
union return type, and forces the call chain to morph whenever
alternatives are added. The logical conclusion to that is that all subs
return Either Exception or Value, so all types should be implicitly
Either Exception or {your text here}. If that's so, then it's a
language feature and we're right back at the top of this thread.
Specifically, if I promise you:
sub foo() will return Dog;
and later on I actually wind up giving you:
sub foo() will return Exception::Math::DivisionByZero;
In haskell:
foo :: Either Dog Exception::Math::DivisionByZero
e.g., it can return either the expected type, or the parameter.
Haskell is elegant in that it compromises nothing for soundness, to
respect referential integrity and purity, but it still makes thing
convenient for the programmer using things such as monads
For appropriate definitions of both 'elegant' and 'convenient'. Java
calls this 'checked exceptions', and promises to remind you when you
forgot to type throws Exception::Math::DivisionByZero in one of a
hundred places. I call it using a word to mean its own opposite: having
been exposed to roles and aspects, having to code for the same things in
many different places no longer strikes me as elegant or convenient.
the try/catch paradigm essentially says:
I wanted to call csub Dog foo()/c but there may be times when I
discover, after making the call, that I really needed to call an anonymous
csub { $inner::= sub Exception foo(); $e = $inner(); given $e {...} }/c.
Yes and no.
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
maintenance programmer.
Right. At some level, you're going to have to do that. This to me is
where the err suggestion fits the most comfortably: err (or doh!
:) is a keyword aimed at ad-hoc fixes to problems. It smooths away the
horrid boilerplate needed for using exceptions on a specific basis.
do_something() err fix_problem();
is much easier to read than the current
{ do_something(); CATCH { fix_problem(); }}
by a lot. But only in two conditions: first that all exceptions are
identical, and second that the correct response is to suppress the
exception.
To me that fails because it's like Candy Corn: you only buy it at
Halloween, and then only to give to other people's kids.
As syntactic sugar goes, it's not powerful enough yet.
We're conditionally editing the return stack. This fits right in with
the earlier thread about conditionally removing code from the inside of
loops, IMO. Once you open this can, you might as well eat more than one
worm. Another conceptually similar notion is that of AUTOLOAD. As a perl
coder, I don't EVER want to write
say Hello, world
or die Write to stdout failed.;
-- it's correct. It's safe coding. And it's stupid for a
whole bunch of reasons, mostly involving the word yucky.
It's incorrect because it's distracting and tedious.
http://c2.com/cgi/wiki?IntentionNotAlgorithm
Code which does it is, IMHO bad code because obviously the author
does not know where to draw the line and say this is good enough,
anything more would only make it worse.
For instance, some
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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 implies the programmer catches a breakpoint exception or some such ;) Exception handling is the programmatic automatisation of this process. As such it works the better the closer it is in time and context to the cause and the more information is preserved. But we all know that a usefull program is lossy in that respect. It re-uses finite resources during its execution. In an extreme setting one could run a program *backwards* if all relevant events were recorded! The current state of the art dictates that exceptions are to be avoided when it is possible to handle the error in-line. That exceptions should only be used for exceptional cases, and anything you encounter in the manual pages is not exceptional. I don't agree with this, because it is IMO effectively saying We had this powerful notion, but it turned out to be difficult to integrate post-hoc into our stack-based languages, so we're going to avoid it. Rather than admitting defeat, though, we're going to categorize it as some kind of marginal entity. I don't see exceptions as necessarily being outside the intrinsic causality of the running program. They are non-traditional forms of flow control: event-based programming, if you will, in an otherwise sequential program. We do much the same thing when we talk about coroutines: violate the traditional stack model. We do the same thing again when we talk about aspects: de-localize processing of certain (ahem) aspects of the problem domain. The telling part of aspects, though, was the the first popular implementation (AspectJ) required a preprocessor and a special markup language to implement. Why? Because nobody uses extensibility and Java in the same sentence. I guess aspects are traditional in that regard, though: remember CFront. Perl, OTGH, doesn't have the poor body-image or whatever it is that keeps people afraid to change the syntax. It can't be a method because it never returns to it's caller - it's It beeing the CATCH block? Ahh, no. It in this case is the .resume call. My question was is cresume/c a multi, an object method, or what? This is because the types of exceptions I would want to resume are ones that have a distinct cause that can be mined from the exception object, and which my code can unambiguously fix without breaking the encapsulation of the code that raised the exception. Agreed. I tried to express the same above with my words. The only thing that is a bit underspecced right now is what exactly is lost in the process and what is not. My guiding theme again is the type system where you leave information about the things you need to be preserved to handle unusual cicumstances gracefully---note: *not* successfully, which would contradict the concept of exceptions! This is the classical view of exceptions, and so it is subject to the classical constraints: you can't break encapsulation, so you can't really know what's going when the exception occurs. The reason I like the with approach is that it lets us delocalize the processing, but does _not_ keep the exceptions are violent, incomprehensible events which wrench us from our placid idyll mentality. In that regard, exceptuations are resumable gotos. =Austin
Re: Look-ahead arguments in for loops
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] - $curr, $next {
...
}
???
1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Possible unique nature of the list.
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last, $curr,
$next {
...
}
Which is all but illegible.
=Austin
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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 resultingValue in Haskell is that we _could_ implement it
in perl as Exception|Somevalue in millions of p6 function signatures.
But I don't _want_ to. I want to say MyClass and have the IO subsystem
throw the exception right over my head to the top-level caller.
In haskell it's the job of the Either monad to let you pretend you
aren't doing Exception|Somevalue everywhere.
You can sequence operations in a deeply nested manner, and then
'fail' at some point. Then control flow will just pop back up all
the way with the error, instead of trying to continue.
You don't really need to say 'Either ... ...', you just use do
notation.
For appropriate definitions of both 'elegant' and 'convenient'. Java
calls this 'checked exceptions', and promises to remind you when you
forgot to type throws Exception::Math::DivisionByZero in one of a
hundred places. I call it using a word to mean its own opposite: having
been exposed to roles and aspects, having to code for the same things in
many different places no longer strikes me as elegant or convenient.
I agree with that wholeheartedly, but in haskell you are making no
obligation towards the shape of an exception - it can be 'Either
thing Error' where Error is any data type you like.
In this sense haskell is just as flexible but requires more
abstraction than perl etc. It has it's merits - it's safer, and more
reusable. It tends to win ICFP contests, and so forth.
However, to just get that thing working real fast, without having
to pay too much when the context becomes maintenance instead of
development, i think Perl 6 will be the most suitable language in
the world.
Right. At some level, you're going to have to do that. This to me is
where the err suggestion fits the most comfortably: err (or doh!
:) is a keyword aimed at ad-hoc fixes to problems. It smooths away the
horrid boilerplate needed for using exceptions on a specific basis.
Which is why it's such a nice propsal =)
As syntactic sugar goes, it's not powerful enough yet.
err next # catch all
err Pattern, next # catch some
Putting my code where my mouth is:
sub infix:err (lhs is delayed, Pattern ?$match = Any, rhs is
delayed) {
lhs;
CATCH {
when $match { rhs }
default { die }
}
}
Ofcourse, these can also stack:
my $fh = open file
err rx/Permission Denied/, next
err rx/No such file/, die;
But i don't think this is very useful for one or at the very most
two catches - for anything else it's ad-hoc nature just doesn't
scale as nicely as CATCH blocks, which can be applied to several
error generating blocks of code at once.
Ofcourse, true acid heads can always say:
do {
...;
...;
} err ..., ...
err ..., ...;
but that's their problem. =)
The last sentence is telling, I think. The run-time system SHOULD take
as much care as possible. And rub my feet.
Yes =)
True for any method that invokes exit(), no? Or that says NEXT on a
label outside its scope.
Well, that's a semantic detail. The issue is that those methods
*can* return, but don't.
A continuation will never return - because it already has another
place to return - the place that created it.
This is ignoring CPS, ofcourse, in which every return and every call
is a continuation. While this may be true under the hood, this is
not what the average Perl 6 user can observe.
The scenario is that I try something (error_throwing_code) and catch an
exception. Then while showing a dialog box to the user, for example, I
get another exception: not enough handles or whatever. So someone higher
than me resolves that on my behalf, then resumes me. I'm still trying to
resume the error thrown earlier:
Yes, that should work.
Now I need to ask, what happens when show_dialog_box throws an
exception? Presumably, I don't catch it in this code path, or there will
be a stack fault shortly.
If the exception from show_dialog_box was thrown, and another CATCH
handler fixed it for you, you don't need to worry about it - you can
never know because you don't get access to that exception. It's as
if it was never propagated.
One possibility is that the catcher of an exception knows little or
nothing about the innards of the thrower.
It's the job of exception classes to bridge these - they have a
class, and any number of attributes.
Exception::IO::Open::PermissionDenied
In fact I suspect that Exception::IO::Open enforces a certain type of
fix, too:
class Exception::IO::Open is Exception {
has
Re: Look-ahead arguments in for loops
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last, $curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
sub contextual (@list) {
return [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef]
}
for contextual( create_list_here() ) - $last, $curr, $next {
...
}
The horror!!!
;-)
Damian
RE: Look-ahead arguments in for loops
-Original Message-
From: Damian Conway [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 01, 2005 8:53 AM
To: perl6-language@perl.org
Subject: Re: Look-ahead arguments in for loops
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last,
$curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
sub contextual (@list) {
return [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef]
}
for contextual( create_list_here() ) - $last, $curr, $next {
...
This looks useful enough to be in the core, but it needs a couple of
parameters, one to say how many copies of the list it zips up, and another
to say what the first offset is.
sub contextual($number_of_copies, $first_offset, @list) {...} # I'm not
sure how to write it.
Then your example would be
for contextual(3, -1, create_list_here() )- $last, $first, $next {
Joe Gottman
Parrot 0.3.0 Alex Released!
On behalf of the Parrot team I'm proud to announce the release of Parrot 0.3.0. I'd like to thank all involved people as well as our sponsors for supporting us. What is Parrot? Parrot is a virtual machine aimed at running Perl6 and other dynamic languages. Parrot 0.3.0 changes and news - New calling conventions implemented: see PDD03 for details - Merge multiple Parrot bytecode (PBC) files into a singe PBC file - 'make smoke' target going beta - bc now supports if statements, comparison ops, prefix inc/dec - ParTcl adds [lassign], [switch] (partially); [expr] converted to a compiler - Many exciting doc updates, tests, and bugfixes, too numerous to mention After some pause you can grab it from http://www.cpan.org/authors/id/L/LT/LTOETSCH/parrot-0.3.0.tar.gz. As parrot is still in steady development we recommend that you just get the latest and best from SVN by following the directions at http://www.parrotcode.org/source.html Turn your web browser towards http://www.parrotcode.org/ for more information about Parrot, get involved, and: Have fun! leo
Re: Look-ahead arguments in for loops
On Fri, Sep 30, 2005 at 08:39:58PM -0600, Luke Palmer wrote: Incidentally, the undef problem just vanishes here (being replaced by another problem). Which reminds me that this same issue came up a while ago in a different guise. There was a long discussion about the reduce functionality that takes an array and applies an operator to each value and the previously collected result. (Much of the discussion was on determining what the identity value for an operator was to initialize the previous result.) Most of the time that you want a loop that remembers the previous value, it can be equally well expressed an a reduction of the series of value using an customer defined operator. I forget what the final choice was for syntax for the reduce operator (it was probably even a different name from reduce - that's the APL name), but it would be given a list and an operator and run as: my $running = op.identity; $running = $running op $_ for @list; So, to get a loop body that knows the previous value, you define an operator whose identity is the initial value of the list and reduce the rest of the list. --
Re: Look-ahead arguments in for loops
On 10/1/05, John Macdonald [EMAIL PROTECTED] wrote:
I forget what the final choice was for syntax for the reduce
operator (it was probably even a different name from reduce -
that's the APL name), but it would be given a list and an
operator and run as:
my $running = op.identity;
$running = $running op $_ for @list;
So, to get a loop body that knows the previous value, you
define an operator whose identity is the initial value of the
list and reduce the rest of the list.
And that was never quite resolved. The biggest itch was with
operators that have no identity, and operators whose codomain is not
the same as the domain (like , which takes numbers but returns
bools).
Anyway, that syntax was
$sum = [+] @items;
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
Luke
Re: Look-ahead arguments in for loops
Damian Conway wrote:
Austin Hastings wrote:
All of these have the same solution:
@list = ...
for [undef, @list[0...]] ¥ @list ¥ [EMAIL PROTECTED], undef] - $last, $curr,
$next {
...
}
Which is all but illegible.
Oh, no! You mean I might have to write a...subroutine!??
Austin Hastings wrote:
1. Requirement to repeat the possibly complex expression for the list.
2. Possible high cost of generating the list.
3. Possible unique nature of the list.
The subroutine addresses #1, but not 2 or 3.
Also, there's a #4: modified state, which is hinted at but not really
covered by #3.
=Austin
Re: seeing the end of the tunnel
On 10/1/05, David Storrs [EMAIL PROTECTED] wrote: All in all, I think that might just be the end of the tunnel up ahead. Go us for getting here, and loud applause to @Larry for guiding us so well! Applause for p6l for hashing out the issues that we didn't think of. I recently wrote a Perl 6 design TODO, which was surprizingly small, which enumerated the things to be done before I considered the design of Perl 6 to be finished. Larry replied with a couple more items. In particular: Here are the chapters which haven't been covered yet: * 17. Threads * 26. Plain Old Documentation * 29. Functions Luke
Re: Look-ahead arguments in for loops
Austin Hastings wrote: 1. Requirement to repeat the possibly complex expression for the list. 2. Possible high cost of generating the list. 3. Possible unique nature of the list. The subroutine addresses #1, but not 2 or 3. It does address 2. The list is generated once (wherever) and only passed to the subroutine once. No regeneration required. It's exactly like your all but illegible solution, just factored out and deuglified. Since I don't understand what you mean by 3, I can't really judge whether it addresses it. But I *can* say it addresses it exactly as well as your all but illegible solution did. Also, there's a #4: modified state, which is hinted at but not really covered by #3. 4 is not possible using the pointy sub syntax in any form, since all params to pointy subs are always constant aliases. Damian
Re: Look-ahead arguments in for loops
On Sat, Oct 01, 2005 at 02:22:01PM -0600, Luke Palmer wrote:
And the more general form was:
$sum = reduce { $^a + $^b } @items;
Yes, it is called reduce, because foldl is a miserable name.
So, the target of running a loop with both the current
and previous elements accessible could be written as either:
reduce :identity undef
{ code using $^prev and $^cur ... ; $^cur }
@items;
or:
reduce :identity @items[0]
{ code using $^prev and $^cur ... ; $^cur }
@items[1...];
--
