develooper Front page | perl.perl5.porters | Postings from March 2020

Thoughts in the direction of a core try/catch syntax

Thread Next
From:
Paul "LeoNerd" Evans
Date:
March 5, 2020 17:38
Subject:
Thoughts in the direction of a core try/catch syntax
Message ID:
20200305173837.43a82822@shy.leonerd.org.uk
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/

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About