Re: End-of-scope actions: do/eval duality.
Thanks, Bart. So Tony, it looks like RFC 88, because of its tight coupling of exception and failure handling, needs to address the issue of "do FILE" that Bart mentions can set $@. This is an issue that results solely from the coupling of exception and failure handling, not from the syntax and semantics of exception handling, so RFC 119 is unaffected. Bart Lateur wrote: > On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote: > > >In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is > >set to the result of an eval or do. How does this impact exception > >handling tests on $@ to determine if an exception was thrown, if $@ can > >be set by a do ? OR is that an error in the pocket guide? > > No, it's a misunderstanding between you and Tony. The "do" your > reference is talking about, is of the form > > do FILE > > where file is a string containing a filename, while Tony is talking > about the > > do BLOCK > > form. do FILE behaves just like eval() (except it reads its data from a > source file), while do BLOCK doesn't. Neither. > > -- > Bart. -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers - Stuff below this added by NetZero - Shop online without a credit card http://www.rocketcash.com RocketCash, a NetZero subsidiary
Re: End-of-scope actions: do/eval duality.
On Thu, 15 Feb 2001 10:04:51 -0300, Branden wrote:
>Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
>little too much not-orthogonal? Why don't we require `eval { do FILE }' to
>have the behaviour of not dying and setting $@ ?
The reason for its existence is simple: history. "do FILE" dates from
before "eval BLOCK". The only way it could have been like you say,
would, at the time, have been:
eval "do \'$file\'";
which is simply horrible (and possibly buggy, if $file contains an
apostrophe or a couple of backlashes).
--
Bart.
Re: End-of-scope actions: do/eval duality.
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote: > > I find a "let's require some extra hoops and red tape" not very-Perl like. > > Perl is there for the programmer; not the other way around. > > Please read ``Larry's talk in Atlanta about Perl 6'', the text is in > http://dev.perl.org/~ask/als/larry-als.txt, you can find it in > http://dev.perl.org. Read the fifth paragraph under `[Simplifications]'. Having read that many times over, I agree with Abigail. You can't just magically invoke Larry and expect that to prove your point. Or prove that you have a point. -- For me, UNIX is a way of being. -Armando P. Stettner
Re: End-of-scope actions: do/eval duality.
On Thu, Feb 15, 2001 at 05:58:34PM -0300, Branden wrote:
> <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> > > Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> > > little too much not-orthogonal? Why don't we require `eval { do FILE }'
> to
> > > have the behaviour of not dying and setting $@ ?
> >
> > And that would gains us what exactly?
> >
> > As the Perl man page says, do FILE is like
> > scalar eval `cat FILE`;
> > If you take out the eval, you get:
> > scalar `cat FILE`;
> > which is pretty pointless.
> >
> > I find a "let's require some extra hoops and red tape" not very-Perl like.
> > Perl is there for the programmer; not the other way around.
> >
>
>
> Please read ``Larry's talk in Atlanta about Perl 6'', the text is in
> http://dev.perl.org/~ask/als/larry-als.txt, you can find it in
> http://dev.perl.org. Read the fifth paragraph under `[Simplifications]'.
Ah, you mean the paragraph were Larry suggest renaming homonyms?
Requiring to write "eval {do FILE}" were you first wrote "do FILE;"
seems quite opposite to what he says.
Keeping the semantics but making it "include FILE" seems to be more
in the line what he means.
But then, it might be better to wait till Larry has spoken.
Abigail
Re: End-of-scope actions: do/eval duality.
<[EMAIL PROTECTED]> wrote:
> On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> > Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> > little too much not-orthogonal? Why don't we require `eval { do FILE }'
to
> > have the behaviour of not dying and setting $@ ?
>
> And that would gains us what exactly?
>
> As the Perl man page says, do FILE is like
> scalar eval `cat FILE`;
> If you take out the eval, you get:
> scalar `cat FILE`;
> which is pretty pointless.
>
> I find a "let's require some extra hoops and red tape" not very-Perl like.
> Perl is there for the programmer; not the other way around.
>
Please read ``Larry's talk in Atlanta about Perl 6'', the text is in
http://dev.perl.org/~ask/als/larry-als.txt, you can find it in
http://dev.perl.org. Read the fifth paragraph under `[Simplifications]'.
- Branden
Re: End-of-scope actions: do/eval duality.
On Thu, Feb 15, 2001 at 10:04:51AM -0300, Branden wrote:
> Bart Lateur wrote:
> >
> > No, it's a misunderstanding between you and Tony. The "do" your
> > reference is talking about, is of the form
> >
> > do FILE
> >
> > where file is a string containing a filename, while Tony is talking
> > about the
> >
> > do BLOCK
> >
> > form. do FILE behaves just like eval() (except it reads its data from a
> > source file), while do BLOCK doesn't. Neither.
> >
>
> Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
> little too much not-orthogonal? Why don't we require `eval { do FILE }' to
> have the behaviour of not dying and setting $@ ?
And that would gains us what exactly?
As the Perl man page says, do FILE is like
scalar eval `cat FILE`;
If you take out the eval, you get:
scalar `cat FILE`;
which is pretty pointless.
I find a "let's require some extra hoops and red tape" not very-Perl like.
Perl is there for the programmer; not the other way around.
Abigail
Re: End-of-scope actions: do/eval duality.
Bart Lateur wrote:
>
> No, it's a misunderstanding between you and Tony. The "do" your
> reference is talking about, is of the form
>
> do FILE
>
> where file is a string containing a filename, while Tony is talking
> about the
>
> do BLOCK
>
> form. do FILE behaves just like eval() (except it reads its data from a
> source file), while do BLOCK doesn't. Neither.
>
Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
little too much not-orthogonal? Why don't we require `eval { do FILE }' to
have the behaviour of not dying and setting $@ ?
- Branden
Re: End-of-scope actions: do/eval duality.
On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote: >In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is >set to the result of an eval or do. How does this impact exception >handling tests on $@ to determine if an exception was thrown, if $@ can >be set by a do ? OR is that an error in the pocket guide? No, it's a misunderstanding between you and Tony. The "do" your reference is talking about, is of the form do FILE where file is a string containing a filename, while Tony is talking about the do BLOCK form. do FILE behaves just like eval() (except it reads its data from a source file), while do BLOCK doesn't. Neither. -- Bart.
Re: End-of-scope actions: do/eval duality.
Glenn Linderman wrote:
>
> Tony Olekshy wrote:
>
> > Traditionally Perl has had both the "do" and the "eval" block
> > forms, the latter which traps, the former which doesn't.
>
> In the perl 5 pocket reference 3rd edition page 63, it claims that
> $@ is set to the result of an eval or do. How does this impact
> exception handling tests on $@ to determine if an exception was
> thrown, if $@ can be set by a do ? OR is that an error in the
> pocket guide?
The following program
$@ = 0; eval { 1 }; print '$@: ', $@, "\n";
$@ = 0; eval { die 2 }; print '$@: ', $@;
$@ = 0; do { 3 }; print '$@: ', $@, "\n";
$@ = 0; do { die 4 }; print '$@: ', $@;
which produces the following results
$@:
$@: 2 at ... line 2.
$@: 0
4 at ... line 4.
would suggest that
- eval{} always touches $@, setting it to undef or some
die's argument, and unwinding (if any) is terminated.
It does not set $@ to the result of the eval.
- do{} doesn't touch $@ unless the block throws, in which
case $@ is some die's argument, and unwinding begins.
It does not set $@ to the result of the do.
If so, it would appear that the pocket reference has it wrong,
and that the traditional operation of "do" is not affected by the
details of any try/throw/except/always/catch/finally mechanism
that specifies a particular behaviour for $@. From an exception
handling perspective, "do" is transparent.
Yours, &c, Tony Olekshy
Re: End-of-scope actions: do/eval duality.
Tony Olekshy wrote: > Traditionally Perl has had both the "do" and the "eval" block > forms, the latter which traps, the former which doesn't. In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is set to the result of an eval or do. How does this impact exception handling tests on $@ to determine if an exception was thrown, if $@ can be set by a do ? OR is that an error in the pocket guide? -- Glenn = Even if you're on the right track, you'll get run over if you just sit there. -- Will Rogers - Stuff below this added by NetZero - Shop online without a credit card http://www.rocketcash.com RocketCash, a NetZero subsidiary
End-of-scope actions: do/eval duality.
John Porter wrote: > > There is no try, there is only do. :-) Nonsense. Traditionally Perl has had both the "do" and the "eval" block forms, the latter which traps, the former which doesn't. "try" is just a slightly souped-up "eval" that better handles the class of problems introduced when exceptions are more commonly used for error handling (by adding some well-defined auxiliary clauses to the statement). Perl has always used an in-flow statement (namely "eval") to signal an unwind-trapping context; are you *sure* you want to change that tradition now? If we work together on this we can make Perl 6's exception handling something worth having worked on. If we throw a bunch of untested ideas together we can only hope they work (at least I hope they work, since Perl has been my favourite language for the last twelve years). Now, shall we? Yours, &c, Tony Olekshy
