Maybe it's Just Nothing (was: Look-ahead arguments in for loops)
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 would be assuming there was always at least one non-optional
> binding. Given that Luke's against all-optional signatures, too, I'll
> withdraw that part of the suggestion. And with at least one required
> binding, then there's no reason that we can't have the window extend on
> both sides of the current value.
>
> Luke?
Hm, I'm being called upon now.
Well, then I start to ask questions like:
for 1..10 -> ?$a, $b, ?$c, $d, ?$e {...}
Which simply doesn't make any sense to me. Also, figuring out such
things (as is the case with lookbehind argumentS) needs a little bit
too much knowledge about the signature of the function you're viewing.
So instead of sticking that in the signature, we could do it with
adverbs on for:
for 1..10, :lookbehind(1) :lookahead(1) -> $cur, ?$left, ?$right {
...
}
You'll note that, unfortunately, the lookbehind has to come *after*
the cur argument because it must be optional. Hmm... actually, that
doesn't work, because at the beginning of the list you won't have a
$left, and at the end you won't have a $right.
It's possible that it's time to start kicking undef into gear. Until
now in Perl culture, undef has been just a little bit special, with
people not fearing to put it in lists and data structures. There may
be benefit in making it more special, so that people shouldn't define
their own meaning for it. Making exceptions undefs are a step in that
direction. If we take another step in that exact same direction, we
could make undefs exceptions (the converse of before):
sub foo() {
return undef;# almost the exact same as "fail"
}
That is, under "use fatal", all undef return values are converted into
exceptions.
That was somewhat beside the point, but not really. If undefs are a
bit taboo--for example, actually writing "undef" in most code is
considered bad style--then we can steal them for the language's
purposes, such as passing to a for block as lookbehind and lookahead
parameters when you're near the beginning or end of a list.
It seems like I'm making a pretty big deal out of just passing undef
when there is no look-behind/-ahead, but I really want to be able to
distinguish between "there was an undef in the list" and "we're almost
done, so there was actually nothing here". Of course, I still don't
get to distinguish those, but a list with an undef in it becomes much
less common.
The way we can help ease the pain of undef not being available for
user purposes anymore is to allow easy manipulation of Either types.
If you define "easy" weakly, then union types give us that:
union Maybe[::t] (Nothing, Just(::t));
Mmm, Haskellicious. But of course you wouldn't need to declare your
types everywhere because of Perl's dynamic typing/type inference
(depending on your mood). Nothing is nice, but I wouldn't call
working with Just "easy" for Joe Schmoe. It's nice and safe, but it's
annoying sometimes. What I might think I want is:
union Maybe[::t] (Nothing, ::t); # not legal union syntax
You lose a lot with that, though. For instance, Just(Nothing) becomes
unrepresentable. And consequently, nested calls to things that return
Maybes become woosy. So that's not a good idea.
So allowing the definition of Maybe is a good start. But it's
difficult to know whether Perl programmers will put up with it. It's
easier--lazier--just to use undef.
Maybe we ought to call the whole thing off. Undefs have no stigma,
and everything is as usual. If you want to iterate over a list with
lookahead and lookbehind, you shouldn't have put undefs in your list.
The last thing to do, if we want to keep the undef status quo, is to
define Maybe in the language and use it for things like for's
lookahead binding. It's kind of like a "formal undef", something like
"listen, it's pretty common that I won't give you a value here, so I'm
going to mark it specially when I both do and do not". Again, not
easy enough; too much abstraction to think about for an everyday task.
I think my favorite so far is the previous paragraph's resolution.
Just because it's my favorite doesn't mean I'm happy with it.
Oh, right, and as for my favorite actual usage of for:
for @list, :lookbehind(2) :lookahead(1)
-> $behind1, $behind2, $value, $ahead {
...
}
Luke
Re: Look-ahead arguments in for loops
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 last.
>>
>>
>
>I disagree, I think that is an easy call
>
>for (1, 2) -> ?$prev, $cur, ?$next {
> say "$prev -> $cur" if $prev;
> say $cur;
> say "$cur -> $next" if $next;
> say "next";
>}
>
>should print
>
>1
>1 -> 2
>next
>1 -> 2
>2
>next
>
>
>
Did you mean:
next
1 -> 2 # two spaces
there?
I assume so because it's the only execution path that seems to work. But
that would be assuming there was always at least one non-optional
binding. Given that Luke's against all-optional signatures, too, I'll
withdraw that part of the suggestion. And with at least one required
binding, then there's no reason that we can't have the window extend on
both sides of the current value.
Luke?
=Austin
>Matt
>--
>"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
>-Stan Kelly-Bootle, The Devil's DP Dictionary
>
>
>
Re: Look-ahead arguments in for loops
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. We've already seen idioms like
>>
> for (;;) ...
>
> If you specify your minimum arity as 0, then you're obviously planning to
> deal with it. This presumes that iterators can handle behind-the-scenes
> updating, of course.
Well, I see two reasons for not allowing arity zero. First, I think
it's too easy to come up with a function with minimum arity zero:
my @lengths = @list.map:&length # oops, infinite loop
Second, you don't get anything by doing this:
for @list -> [EMAIL PROTECTED] {
...
}
As it's equivalent to:
loop {
...
}
Where you use @list instead of @items.
Luke
Re: Look-ahead arguments in for loops
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 think that is an easy call
for (1, 2) -> ?$prev, $cur, ?$next {
say "$prev -> $cur" if $prev;
say $cur;
say "$cur -> $next" if $next;
say "next";
}
should print
1
1 -> 2
next
1 -> 2
2
next
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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 is delayed) { # we really need
thunk parameters
return $lhs dor $rhs;
CATCH { return $rhs }
}
So really 'err' is just 'dor' with an added error silencer.
> On the primary hand, I don't like the idea of using "err" as a try/catch
> because that's putting exception handling in line with the primary code.
> See FMTYEWT below.
Isn't
no fatal;
my $fh = open $file or die;
...
my $fh = open $file or next;
also putting exception handling in line with the primary code?
Isn't that useful?
Exception handling should be put in wherever there is well defined
behavior on how error conditions should be dealt with.
It's Perl's job to make this as easy as possible for the programmer.
If we have a module called File::Slurp::Some, which doesn't really
care if some of the files don't exist, it's code would, IMHO be
much more readable with
open $file err next;
than a catch block.
The reason for this is that a catch block is always detached from
the code.
However, if the error is part of the normal flow (it is no longer
exceptional for the file to not exist), what benefit does the added
detachment give?
> 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
> 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
> the try/catch paradigm essentially says:
>
> I wanted to call sub Dog foo() but there may be times when I
> discover, after making the call, that I really needed to call an anonymous
> sub { $inner::= sub Exception foo(); $e = $inner(); given $e {...} }.
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.
> 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.
> But I acknowledge that through the miracle of broken pipes, it can
> legitimately happen that stdout will fail while stderr is a viable
> diagnostic mechanism.
the default $SIG{PIPE} handler is a wonderful example of how nice
exception handling is for naive code.
$SIG{PIPE}'s only problem is that it's completely non standard.
> But the default behavior (modulo threads) is going to unlink all the
> stack frame pages when the continuation is invoked.
Forget the stack... Perl is CPS under the hood, even if it's
optimized not to be that way.
> So there has to be yet another copy of the links to the stack,
> because the exception handling will want to call functions and
> build who-knows-what elaborat
Re: Look-ahead arguments in for loops
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 and bind the maximum
>>arity. Of course, the minimum arity has to be >= 1 lest an infinite
>>loop occur.
>
>
Or not. We've already seen idioms like
for (;;) ...
If you specify your minimum arity as 0, then you're obviously planning to deal
with it. This presumes that iterators can handle behind-the-scenes updating, of
course.
>>But then perhaps you have another way to avoid integer
>>indices:
>>
>>for @list -> $this, [EMAIL PROTECTED] {
>>...
>>}
>>
>>As long as you don't look backwards. Looking backwards makes problems
>>for GC in lazy contexts, so this might just be perfect.
>
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.
=Austin
Re: Look-ahead arguments in for loops
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 course, the minimum arity has to be >= 1 lest an infinite
loop occur. But then perhaps you have another way to avoid integer
indices:
for @list -> $this, [EMAIL PROTECTED] {
...
}
As long as you don't look backwards. Looking backwards makes problems
for GC in lazy contexts, so this might just be perfect.
Luke
Re: Look-ahead arguments in for loops
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. Could we imbue optional binding with the semantics of not being
> consumed?
>
> for grep {defined} @in -> $item, ?$next {
> print $item unless defined $next && $item eq $next;
> }
>
> The same behavior, but without the variable outside the loop scope.
>
>
> It would also be good not to overload the meaning of $?next to also
> tell us if we're at the end of the loop. In addition to FIRST{} and
> LAST{} blocks, could we have some implicit lexicals:
>
> for @in -> $item, ?$next {
> print $item if $?LAST || $item ne $next
> }
>
I like the idea. There's no reason the view window and the consumption
have to be the same.
=Austin
Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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 syntactic sugar for a very small try/CATCH
>>> block.
>>
>>
You already know that "err" is the low-precedence version of //, right?
What replaces that? I like "default" or "defaults" myself, but I'm never
really sure what the precedence actually IS. After all, "and"/"or" were
lower than assignment, so you could code:
$a = foo or die;
and get ($a or die). How does this work for the "err"/"defaults"
keyword? Does the low-precedence version move up, or is there an idiom I
don't understand?
On the primary hand, I don't like the idea of using "err" as a try/catch
because that's putting exception handling in line with the primary code.
See FMTYEWT below.
>>
>> I like it a lot. It gives the advantages of both the flexible, more
>> robust try/catch, and the (locally) concise, clear error return.
>
>
> I don't like it at all. I fear, that we mix two orthogonal concepts
> just because it is convenient.
>
> To me the statement
>
> return 42; # 1
>
> has to orthogonal meanings:
>
> 1) the current scope has reached its (happy) end
> 2) a specific result was determined
>
> We can vary on both of these dimensions *independently*!
> Which gives the remaining three cases:
>
> return undef; # 0 unspecific result
> fail undef; # -1 no return with unspecific reason
> fail 42;# -2 no return but determined reason
>
> In other words an exception means
>
> return !caller;
>
> or in yet another way to describe my attitude: the least
> thing that *defines* an exception is that the dynamic
> scope in question has reached the conclusion that it
> is *not* going to give control back to its creator!
But it *does* give control, albeit briefly, back to its caller.
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.
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;
the try/catch paradigm essentially says:
I wanted to call sub Dog foo() but there may be times when I
discover, after making the call, that I really needed to call an anonymous
sub { $inner::= sub Exception foo(); $e = $inner(); given $e {...} }.
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". But I acknowledge that
through the miracle of broken pipes, it can legitimately happen that
stdout will fail while stderr is a viable diagnostic mechanism.
Instead, I want PERL to fill that in for me: I believe that the default
error mechanism should debug my program, the shell script that calls my
program, and the actions (including blood alcohol content) of the user
of my program over the last 24 hours: lets leave use autodebug;
turned on by default.
The 'Exceptuation' proposal seems to me to include two things:
1. A 'RESUME' feature.
2. An implicit acknowledgement that the default implementations are
parallel:
{...
CATCH -> $e {throw $e;} # Going up?
RESUME -> $r {resume $r;} # Going down?
}
The rest is optimization. If caller() includes an array of
continuations, then throw looks like a loop up the array:
sub throw(Exception $e)
{
reverse caller() ==> { .continuation($! => $e) if does(CATCH); }
}
But the default behavior (modulo threads) is going to unlink all the
stack frame pages when the continuation is invoked. So there has to be
yet another copy of the links to the stack, because the exception
handling will want to call functions and build who-knows-what elaborate
skycastles. And it must be reentrant because of the possibility of
exceptions during the exception handling. Which means that the call
stack needs to be stored in the Exception. [The list of things in the
exception gets pretty long. I'm sure it's all a ref to the last page of
the call stack, so it doesn't gobble up much space, but there's a lot of
"and you'll want"s coming up.]
So resume is a multi, no? (Or it could just be a method:
$!.resume, but that doesn't read as well in a block that *really* sho
Look-ahead arguments in for loops
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 binding with the semantics of not being
consumed?
for grep {defined} @in -> $item, ?$next {
print $item unless defined $next && $item eq $next;
}
The same behavior, but without the variable outside the loop scope.
It would also be good not to overload the meaning of $?next to also tell
us if we're at the end of the loop. In addition to FIRST{} and LAST{}
blocks, could we have some implicit lexicals:
for @in -> $item, ?$next {
print $item if $?LAST || $item ne $next
}
Re: skippable arguments in for loops
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 undef", much like "1" means "this has to be 1". In Perl6 we currently have at least tw oways to say "don't care": In a regex, we say /./ to match anything; in a type signature, we use "Any" to mean that we don't care what the type is. I don't think we need another way to say "don't care". In fact, we could unify things: rules: // matches anything (/./ is shorthand synonym) binding: ($a, Any, $b) := (1,2,3); I'll admit that "Any" doesn't immediately shout "skip", but it would really be the fact that there's no variable associated with it that means "skip", If we'd wanted to skip an integer, we could say: ($a, Int, $b) := (1,2,3); Why would Perl need to add "_" as a synonym for "Any"? It's only a couple of characters shorter! The argument for /./ being a synonym in rexen is easier to make: it's common, it's legacy, and it's 4 chars shorter.
Re: use fatal err fail
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 idea.
For the example given, I'd rather write
my $fh = try {open $_; CATCH {next} };
and still fit it on 1 line!
For what it's worth, I'd like to chime in on 'yes please' for having
fatals on by default.
I've been hanging round some perl forums lately, and it's such a
basic, recurrent issue.
Cheers,
Carl
Re: use fatal err fail
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 advantages of both the flexible, more
>> robust try/catch, and the (locally) concise, clear error return.
>
> I don't like it at all. I fear, that we mix two orthogonal concepts
> just because it is convenient.
I agree with you, TSa. I'd like to add that we don't have to do without
convenience in the majority of cases:
use fatal;
for @files {
my $fh = try { open $_ } err next;
load_config_from($fh);
}
* try {...} is, like Perl 5's eval {...}, *not* statement-level.
This means you can easily wrap it around an expression.
Particularly you can write
my $fh = try { open $_ } err next; # instead of
my $fh;
try {
$fh = open $_;
CATCH { next }
};
* Yes, "try {...} err ..." does not check the exception type, but
the proposed "... err ..." doesn't either.
* "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 }
FWIW, I also agree with Darren that "use fatal" should be on by default.
--Ingo
Re: Exceptuations
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 and > possibly Event::Hint, Event::Log and Event::Fun :) > > The only drawback of choosing 'Event' might be that it > smells too GUIish for some? Or is that a feature? That is > we get Event::GUI::press, Event::GUI::scroll, Event::GUI::expose, > etc. FSM etc. http://en.wikipedia.org/wiki/Event_driven_finite_state_machine Running Perl code can be seen as an ATN (an FSM on steroids, says http://smc.sourceforge.net/SmcFaq.htm). An exception-handler can be allowed to pop more states than it is good for. -- Grtz, Ruud
Re: use fatal err fail
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) the current scope has reached its (happy) end >2) a specific result was determined return literally means "give back". The caller is getting a value that we give. This implies two completely non-orthogonal meanings to me: 1) the scope has reached its happy end 2) it's reached the end because a specific result was determined > We can vary on both of these dimensions *independently*! > Which gives the remaining three cases: > >return undef; # 0 unspecific result just 'return' would do. But This is odd, unless the context is void - if the caller is expecting something, wer're not returning an "unspecific result" - we're returning a value. This value is in bounds (it's a normal perl scalar) and it has a well known meaning that "i have have nothing meaning to report". I think this is actually a very concrete result. >fail undef; # -1 no return with unspecific reason >fail 42;# -2 no return but determined reason Fail is, semantically: (should_die ?? die !! return) and the caller gets to determine the behavior. Whether failures have an extras payload in a simple return value, or whether the payload is carried via an out of bounds route to the closest thing that can handle is really only dependant on how the caller is most comfortable with handling errors. > or in yet another way to describe my attitude: the least > thing that *defines* an exception is that the dynamic > scope in question has reached the conclusion that it > is *not* going to give control back to its creator! Not at all! It's simply returning an out of bounds value to the closest caller that is willing to handle out of bounds values. In fact, it's short circuiting to it's caller, to give it control as fast as possible since it doesn't know what to do anymore. The reason exceptions tend to pop upwards more is that they are handled in a way that if the immediate caller doesn't know how to handle it either, it keeps going up the call stack till a calling scope does know what to do, and can explcititly take control. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me beats up some cheese: neeyah! pgpqFx7QmiXTK.pgp Description: PGP signature
Re: use fatal err fail
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 very small try/CATCH block. I like it a lot. It gives the advantages of both the flexible, more robust try/catch, and the (locally) concise, clear error return. I don't like it at all. I fear, that we mix two orthogonal concepts just because it is convenient. To me the statement return 42; # 1 has to orthogonal meanings: 1) the current scope has reached its (happy) end 2) a specific result was determined We can vary on both of these dimensions *independently*! Which gives the remaining three cases: return undef; # 0 unspecific result fail undef; # -1 no return with unspecific reason fail 42;# -2 no return but determined reason In other words an exception means return !caller; or in yet another way to describe my attitude: the least thing that *defines* an exception is that the dynamic scope in question has reached the conclusion that it is *not* going to give control back to its creator! Note that this somewhat pinpoints or controls the two infinities of computing in time and storage. One either needs a block of infinite length right away or handle control flow exceptions *on the outside* to keep a finite scope going. -- $TSa.greeting := "HaloO"; # mind the echo!
Re: Exceptuations
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 calculated value of a quantity and it's true value. As i see it: when something you wanted to happen turned out different than you programmed it to: my $handle = open "file"; # we assume $handle exists print =<$handle>; # but what if there was an error? exception - a person or thing that is excluded from a general statement or does not follow a rule To lessen the mental load on a programmer, instead of having the programmer write a tree of all the conditions that could happen, the programmer can write only the condition in which the program is actually useful. Any *error* (synch problems between the code and reality) causes an *exception* in this linearization. The control flow is an exception to the norm, because there was an exception in the reality the program was tailored to deal with. The reason we handle exceptions is that sometimes we want the tree approach, because we have well defined behavior for certain paths. Exceptions let us separate code from "normal" code and code which is *exceptional*, and the reason it is exceptional is usually an error. event - a thing that happens, especially one of importance Every error is an event. Exceptions are one way to deal with events we were not prepared for. But events can also be waited for (select waits for events on many file handles at a time). Every *error* is an *event*, but an *exception* is how you deal with events. The events that cause exceptions by default in perl will be: errors, when 'use fatal' is in effect warnings, but to another handler next, redo, last, return - all control flow events that are exceptions to the single point of entry, single point of exit school of thought. I intentionally did not use the computer related definitions from e.g. wikipedia, because they are more subject to cultural inertia, and we are trying to discover the roots of these borrowed terms. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me groks YAML like the grasshopper: neeyah!! pgpr89lYnXBsX.pgp Description: PGP signature
Re: use fatal err fail
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 program-external resources should by default throw an exception on failure, including all system calls, file or filesystem operations, network operations, interprocess communications, signals, etc. It is a lot easier to write safe, correctly functioning, and easy to debug programs when problems are detected as early as possible, which a default-active exception architecture ensures. Naive developers will be helped greatly when they forget to account for possible problems, since errors don't crop up in a different place than their cause (eg, at 'print' time when the problem was with the 'open'); if they forget something, Perl will tell them. Saavy developers who don't like the exceptions can explicitly turn them off, the very act of which implies that they know what they're doing and can handle the situations where Perl doesn't help them remember. Considering that its a well known best practice to throw exceptions in one's own non-trivial programs and modules, it would be nice if the core language functions themselves were consistent with that practice. Just as I agree that having 'use strict' turned on all the time and/or being the default, likewise having 'use fatal' turned on all the time and/or by default is also the best course of action. While we're at it, 'use warnings' should probably be on by default too, but this is less important than 'fatal'. -- Darren Duncan
Re: Exceptuations
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 word I use Event and we get > Event::Exception, Event::Control, Event::Warn and > possibly Event::Hint, Event::Log and Event::Fun :) An event is something external that happens... It does not affect the control flow of an application. Exceptions work well to describe this: The normal flow is up and down the call graph, laying bread crumbs in the form of a stack, and going back from where you came. Exceptions let you jump instantly to another place in the call graph. All I'm saying is that to complement the normal "exceptions jump back out", you can jump out, and jump back in. An event is a general thing that can be implemented with exception like semantics, but implies nothing on the control flow of the program. An error is an exception that happenned because something went badly wrong. Now it's my turn at illustrative metaphors ;-) The call graph is a big maze you go through. When you find an *error*, in the form of a minotaur, you use the exception handling mechanism to run away. You jump instantly to a safe place in the labyrinth. Although this is not consistent with the mythology, presume that the reason you entered the maze was that you were trying to get results. Most exception handlers are safe places when you can gather your self, realize that 'oh crap, i just met a minotaur', and tell whoever you sent you in there that there's no way you're going back in. All I'm trying to say is that when there is an exception - a leap out from a dangerous place to a safe one, due to an error, the code may choose to deal with the error by giving you a big stick. Then you can go back and beat the minotaur into submission, and resume with trying to get results. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgp9mjhsoAPUd.pgp Description: PGP signature
Re: Exceptuations
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'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. E.g. a traffic accident is the exceptual case that stops the regular traffic in a certain area. But for medics, firemen and police they are the usual case up to a limit where it also becomes exceptional to them. Take the example of firemen. They are some kind of installed exception handlers. And they can handle flooded basements but New Orleans and Bavaria have thrown a too big exception. Well, or take the engineers of the Titanic, they trusted their installed exception handlers to cope with a breached hull so much that they didn't install enough rescue boats. BTW, I would call *intentional* exceptions terrorism. a warning is simply an exception with two properties. or have a WARN block of its own, I don't know. Or maybe &*EXCEPTION_HANDLER is a multi-method-continuation. ... An MMD exception handler that is extended in the dynamic scope is cool because it's not limitied to just control exceptions, warnings, and fatal errors. Some fun definitions: In lack of a better word I use Event and we get Event::Exception, Event::Control, Event::Warn and possibly Event::Hint, Event::Log and Event::Fun :) The only drawback of choosing 'Event' might be that it smells too GUIish for some? Or is that a feature? That is we get Event::GUI::press, Event::GUI::scroll, Event::GUI::expose, etc. -- $TSa.greeting := "HaloO"; # mind the echo!
