On Wed, Dec 07, 2005 at 09:43:31AM +0100, TSa wrote:
: HaloO,
:
: Larry Wall wrote:
: >My gut-level feeling on this is that $! is going to end up being an
: >"env" variable like $_.
:
: I just re-read about exceptions. Well, I undestand now that $! is
: intented as a variable with a spectrum of meanings ranging from
:
: 1) the return value of a sub, through
: 2) an error return value, up to
: 3) a non-return value.
:
: Of these only the last is what I know as exceptions. I'm for now
: undecided to regard these three purposes of $! as very clever or
: as big potential for subtle problems. From the viewpoint of the
: execution model this environment approach is very clear, though.
: It nicely unifies return values with in-band errors and out-band
: exceptions. Which leaves just one wish from my side: make CATCH
: blocks dispatched. That is they get a signature what kind of
: exception they handle. The optimizer will make good use of this
: information.
I think that's basically the direction that Parrot is headed.
: >Then the problem reduces
: >to what you do with an unhandled $! at the end of a lexical scope,
:
: I don't understand this. The end of scope is either the closing
: brace or an explicit statement like next, leave, return, yield,
: fail or die. In the above spectrum of $! these are resultizer
: just as given, for and friends are topicalizer for $_. But I think
: simple assignment to $! is not foreseen, or is it?
I don't entirely understand it all yet myself. It's possible that we're
trying to unify too many ideas into $! all at once. It may be impossible
to simultaneously do all of:
* emulate Perl 5's $!, $@, $? and $^E
* represent only the "last" exception status
* never lose exception information
Indeed, the faults with Perl 5's $! mechanism are the major reason
for CATCH blocks. So maybe we should just make $! as close to Perl 5
semantics as possible and then steer people away from it if they
want to write robust code.
Even the first of those items above is something we really haven't
thought through. In Perl 5 $! has errno semantics that mean you
shouldn't rely on its value unless something went "bang" and you know
it some other way. Whereas $@ and $? rely respectively on evalish
and systemish calls to clear the variables on success. Does unifying
$! with those mean that $! has to be cleared on every function call?
That seems rather ill-defined. I think the solution is more along
the lines of $! clears its boolean/defined status on every function
call but remembers the last actual exception. Or maybe we just say
that $! stays true if it contains any exception, and rely on eval
or system-like calls to clear $! if they want test-after semantics?
I can argue it both ways, which probably means that neither solution
is the right one.
: For an example let's assume that / returns 'undef but division by zero'
: in $! if its rhs is zero.
Well, NaN probably, but go on.
: { # begin of scope
:
: my $x = 3;
: my $y = 4;
:
: say $x/$y;
:
: $x = foo; # foo could return 0
:
: my $z = $y/$x; # $! == 'undef but division by zero' if $x == 0
: # Is that assignable to $z?
:
: $z++; # This is now a statement in a potential CATCH block?
: }
Yes, the return value is assignable whether it is NaN or undef
(assuming the type of $z doesn't prevent assignment), but the return
value is not quite the same thing as $!, I suspect. It's more like
$! contains a pointer to the latest error return value. Another
way to look at it is that the returned exception value is immutable
(more or less) but $! is mutably bound to some error value.
Larry
