Re: PSC #049 2022-01-07

Front page | perl.perl5.porters | Postings from January 2022

Thread Previous | Thread Next

From:

Paul "LeoNerd" Evans

Date:

January 16, 2022 11:58

Subject:

Re: PSC #049 2022-01-07

Message ID:

20220116115800.0e8e33fa@shy.leonerd.org.uk

On Sun, 16 Jan 2022 12:23:53 +0100
demerphq <demerphq@gmail.com> wrote:

> Hrm, it seems like that would be solution so rjbs could have what he
> thinks is sensibel, and you could have what you think is sensible.
> If one could introspect on the arity of a sub then to some level this
> could be avoided. Eg, when the new framework accepts a sub designed
> for the old 1 argument API, it could internally ensure that  sub was
> called with 1 argument, and call the subs intended for more than 1
> argument as required. If you can't introspect on the arity then you
> can not harden yourself for this. Eg, a forward looking dev could say
> "my callback framework insists the callback accepts a slurpy argument
> list" and warn or die when someone passes in one that doesnt have
> artiy==-1 (-1 for infinity), and one less prescient could do
> something else internally, something like:
> 
> my $arity=arity($sub_ref);
> if ($arity == 1) {
>   $sub_ref->($key)
> }
> elsif ($arity < 0 or $arity == 2 ) {
>   $sub_ref->($key,$index);
> }

...

> Personally I cant understand why if perl can validate the arity of a
> sub we cannot provide a mechanism to determine what that is at a code
> level.

> While in this new PSC world I dont believe my opinion matters much,
> it at all, I personally think you have case to go to rjbs and the PSC
> and say, "I do not want to change the rules about arity, but I *do*
> think we should provide a way to introspect on it", and I think rjbs
> might be a bit more amenable to talk about it if he understand it
> wasnt the "bypass arity checks" argument rehashed. I dont him that
> well, and we do disagree from time to time, but IMO he is usually a
> pretty reasonable guy.

((With my personal hat and not my PSC hat))

I've also been wanting (needing) an arity-inspection mechanism,
currently required to make Syntax::Keyword::MultiSub work.

Also in the presence of such a mechanism it would be possible to write
a little call-wrapper to call a sub with no more arguments than it was
expecting, even if I accept that it will *SILENTLY* discard extra ones:

  sub call_no_arity ($code, @args) {
    my $nmax = max_arity_of $code;
    splice @args, $nmax, -1, () if defined $nmax;
    return $code->(@args);
  }

  ...

  sub each ($code) {
    ...
    call_no_arity $code, $item, $index, $context;
  }

Could be used with any of the following, without error:

  ->each(sub ($item) { ... });
  ->each(sub ($item, $idx) { ... });
  ->each(sub ($item, $idx, $c) { ... });


That said, my ideal wish would be for arity-checking to appear as a
default-fatal exception from the caller's perspective; so the caller
could do something like:

  sub each ($code) {
    ...
    {
      no fatal 'signatures::max_arity';
      $code->($item, $index, $context);
    }
  }

To, within that small lexical scope, disarm the fatality of maximum
arity checking.

-- 
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk      |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Thread Previous | Thread Next