Front page | perl.perl5.porters |
Postings from March 2020
Re: Thoughts in the direction of a core try/catch syntax
Thread Previous
|
Thread Next
From:
hv
Date:
March 6, 2020 00:30
Subject:
Re: Thoughts in the direction of a core try/catch syntax
Message ID:
202003060008.02608rP16072@crypt.org
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> 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?
I'd definitely like to see this available in core, preferably by means
of option 2.
I'll note though that any new semantics made available by encorement
will _not_ have benefited from the battle-hardening of the CPAN
implementation, and we don't have a good recent record of getting such
things right first time.
The list-returning capability does not sound problematic from a semantic
point of view. The type-dispatch implicit in efficient propagation of
unhandled exceptions sounds a lot harder, so if at all possible I'd
suggest again experimenting with that in CPAN - adding (temporary,
experimental) hooks as necessary to permit it - rather than trying
to introduce it in core ab initio.
We don't really have a model for that: the general assumption has been
that if a hook is provided, it is intended to be supported for all time,
and it's p5p's job to cope with every crazy thing anyone might do with it.
I also don't know if it's a solution that lends itself to this problem,
but I suggest that if it does, we should consider a time-limited set of
hooks (ie supported for a release or two) for the specific purpose of
experimenting with these semantics.
Hugo
Thread Previous
|
Thread Next