Front page | perl.perl5.porters |
Postings from June 2020
Re: Thoughts in the direction of a core try/catch syntax
Thread Previous
|
Thread Next
From:
Paul Johnson
Date:
June 27, 2020 12:14
Subject:
Re: Thoughts in the direction of a core try/catch syntax
Message ID:
20200627114831.GA5854@pjcj.net
Top posting because this is an old message and I want to leave it intact
below.
Summary: I'd love to get a very simple try/catch syntax in core as an
experimental feature.
I'm mostly happy with Syntax::Keyword::Try, especially with the
enhancements described below made possible by being core. I don't
really like "finally" as implemented and would be happy to leave it out
of an initial core implementation.
I don't need any kind of type system/matching initially and would
suggest that anything in that area should be more general and shouldn't
be considered for an initial implementation here. I don't really care
what variable the exception ends up in in the catch block. Being fast
would be nice.
I think a simple syntax such as that described below is sufficiently
clean that it should always work, whatever other bells and whistles may
subsequently be added.
And we can make the feature experimental such that it can be changed if
really necessary.
I'd hate for us to get nothing here due to concerns about advanced cases
so I'd love to see the example below, and pretty much just that, in the
core.
On Thu, Mar 05, 2020 at 05:38:37PM +0000, Paul "LeoNerd" Evans wrote:
> I have a CPAN module Syntax::Keyword::Try, which provides a try/catch
> syntax using the keyword plugin mechanism:
>
> use Syntax::Keyword::Try;
>
> sub foo
> {
> try {
> attempt_a_thing();
> return "success";
> }
> catch {
> warn "It failed - $@";
> return "failure";
> }
> }
>
> -- https://metacpan.org/pod/Syntax::Keyword::Try
>
> This has become the preferred try/catch module in several places, such
> as recommended by Freenode/#perl, several companies I work or have
> contracted for, and has been battle-tested in production for a large
> amount of accumulated time now. I believe it is stable and useful.
>
> During the recent(ish) P5H meeting in Amsterdam, this module was
> mentioned as an example of syntax extension on CPAN that ought to
> become core in some fashion or other. I would like to open this
> discussion here.
>
> The words "become core" could mean a couple of different things here, so
> it's important to list them to distinguish them for further discussion:
>
> 1) Does core simply bundle the CPAN module as-is, to make it
> dual-life and shipped with core by default, and to stand as a
> possible in-core example of how to use the keyword mechanism?
>
> 2) Does core reïmplement the exact behavior and semantics of the
> module as real core code, guarded by some feature perhaps
>
> use feature 'try';
>
> at which point, the `sub import` in my existing Try.pm can simply
> trigger that instead, and the XS part of the module becomes a
> legacy implementation only required for older perls?
>
> I would like to vote in favour of the second option; that core perl
> actually implement a real try/catch syntax which is syntactically and
> semantically compatible with the battle-tested S:K:T as it currently
> stands. At that point the CPAN vs core implementations really ought to
> remain aligned in terms of features and behaviour, but as I am likely
> to be the implementer of both I feel that would not be a difficult task
> to maintain during the "dual-life" lifetime - with the view that one
> day far into the future, the CPAN version is no longer needed as any
> reasonable Perl version already supports it in core.
>
> A real core implementation of this module could be implemented a little
> more efficiently in places than my current XS attempt, and could also
> allow a few new advantages; things I cannot implement in XS as it
> stands:
>
> *) list-returning `try do { ... }` semantics.
>
> Currently S:K:T can only provide scalar context, because
> op_contextualize() gets confused about the optrees that I make and
> annotates the final internal expression within the block as
> G_SCALAR
>
> *) unhandled `catch` can propagate to outer contexts.
>
> Currently S:K:T's implementation is forced to catch all
> exceptions. Any type checking/dispatch must be implemented in user
> code, and any exceptions not otherwise handled must be re-thrown.
> This throws away information.
>
> The module currently lacks a type-dispatch mechanism, but if
> one were added then a core implementation would be able to decide
> not to catch a given exception and allow it to propagate to
> callers without needing to be re-thrown.
>
> There are still some outstanding syntax questions on how a type
> dispatch mechanism might be written, but exactly how I attack and
> answer those will depend in part on what the ultimate destination for
> the syntax is. Will S:K:T be forever a CPAN module outside of core, or
> can we find a way to bring it into core for real, and finally[*] bring
> a real try/catch syntax to the Perl5 language?
>
>
> *: Pardon the pun, I couldn't resist...
>
> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>
>
--
Paul Johnson - paul@pjcj.net
Thread Previous
|
Thread Next