Thanks rjbs for giving some thought; my replies below...
On Mon, 25 Jan 2021 22:51:23 -0500
"Ricardo Signes" <perl.p5p@rjbs.manxome.org> wrote:
> Another form of this question is: is catch more like a subroutine or
> more like a for loop? :-)
...
>
> Meanwhile:
> sub declaim ($message) { ... }
...
> If the parametric syntax for subroutines and catch can be unified,
> that seems like a real win. It could become a pattern to be used in
> a number of places. (A new for-ish loop with a parameter list in
> place of a single bind value? I'd use it.) So, that implies "catch
> ($e) { ... }" but the remaining question is: do you need that
> parameter list?
This was verymuch my unifying thought, yes. As laid out by
https://rt.cpan.org/Ticket/Display.html?id=123918#txn-1903905 (hoping that rt.cpan.org links survive into posterity)
Originally I considered it like a for loop, and it was even spelled
`catch my $VAR { ... }` looking very similar. But I found we couldn't
get the typed conditional dispatch in there in any sensible syntax. So
we looked at other things - ilmari suggested the overlap with
signatures.
The basic observation is that there's some syntax similarity along with
the similar behaviours of
catch ($e) { ... }
sub f ($x) { ... }
and I was planning to keep them similar while adding things like `isa`
or `is` type assertions. One can imagine
try { ... }
catch ($e isa SomeException) { ... }
catch ($e isa DifferentException) { ... }
somewhat similar to a sortof multiple dispatch on `multi sub`:
multi sub _catch($e isa SomeException) { ... }
multi sub _catch($e isa DifferentException) { ... }
The similar spelling of the items in parens here follows through to a
deeper similarity in the implicit creation of those lexical variables
and the type assertions for dispatching on them.
I also have a few other thoughts of a few additional language
constructions that again follow similar ideas of looking like
signatures/catch with typed assertions as some sort of conditional
dispatch. I'll be saying more on that subject in my FOSDEM talk - so
perhaps I'll come back to reply here again when that happens on
Feb 6th.
> Well, the behavior of subroutines without a signature is "you look at
> @_, which is different than the ($x, $y) you would've gotten from a
> signature." You get aliases instead of copies, there's no arity, and
> other minor perils apply. Is it reasonable to say "if you have no
> parameter list for catch, you just look at $@, which has some peril"?
...
> One *still* wants to copy $@, because any subroutine inside the "if
> ($@)" might still clobber it. But if there are no subroutines, if
> the programmer really knows what they're doing, trusting $@ is not
> crazy. I think if we can say "when catch is entered, $@ has the same
> value that was thrown with die, with the same guarantees as at the
> end of an eval", then allowing a no-parameter catch block seems
> reasonable and in line with other parts of the language.
I considered allowing that, but I didn't really feel there were any
strong reasons for doing so just yet. There's certainly no
backward-compatibility problem as it is a new syntax. We might as well
start with the most restrictive rules (catch must declare a var), and
if later on we find that keeps getting in the way because people
genuinely do want an unvariabled catch to assign into $@ with all the
volatility risks that involves, we can expand the grammar to allow it.
(Though at that point I'd wonder how you do a `isa` typed catch without
a var).
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk |
https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ |
https://www.tindie.com/stores/leonerd/