develooper Front page | perl.perl5.porters | Postings from June 2022

Re: goto and @_

Thread Previous | Thread Next
June 3, 2022 19:54
Re: goto and @_
Message ID:
Thanks Paul!

Not quite sure I like this very single-use function (where else might
people try to call it and how will this go wrong?), but I have no better

While we're at it, I know you've discussed multi subs and this is even more
interesting to me now (even though I've always favored the idea).

I had this code:

            $method => sub ( $self, $value = undef ) {
                _debug( "Args for overloaded reader/writer for $name", \@_
                return @_ == 1
                  ? $self->$reader_method
                  : $self->$writer_method($value);

But haarg pointed out that the intent was for @_ to go away in signatured
subs. This was the best I could think of:

            $method => sub ( $self, @value ) {
                _debug( "Args for overloaded reader/writer for $name", [
$self, @value ] );
                return @value == 0
                  ? $self->$reader_method
                  : $self->$writer_method(@value);

I'm not passing an array or a list as the second argument. Instead, I'm
stuck pretending that I am and I should have a check for @value having more
than 1 argument. In short, variadic subs aren't handled well by signatures.
If we had multidispatch, much of this ugliness would go away:

    sub some_method :multi ($self) { ... }
    sub some_method :multi ($self, $new_value) { ... }

But that doesn't address how I'd create an anonymous multisub.

So far, I'm loving signatures, but now that I'm converting some code to
deal with the impending removal of @_, I'm less convinced.

Now that I think about it, with a decent introspection mechanism for sub
arguments (including the ability to set them), the tailcall issue would
also go away (and the potential bugs of a single-use function with it)
*and* the
code I just wrote would be much cleaner. I hate @_ because it's just more
punctuation to confuse new developers, but it does what it's supposed to do
quite well. I'm open to suggestions.


On Fri, Jun 3, 2022 at 9:19 PM Paul "LeoNerd" Evans <>

> On Fri, 3 Jun 2022 18:50:19 +0200
> Ovid <> wrote:
> > Is there a plan for this?
> Ish.
> It's known and noted that tailcalls don't work with "no snails"
> currently.
> I have thoughts on adding a `tailcall` to address it, so your code
> would become:
>     use SOMETHING 'tailcall';
>     sub import ( $class, @args ) {
>         my $real_import = get_real_import();
>         # do stuff
>         tailcall $real_import->( $class );
>     }
> Quite where that comes from I don't know. It can't just be a `builtin`
> because it's not just a regular function. It'd have to be something
> else - maybe a `use feature` or somesuch.
> --
> Paul "LeoNerd" Evans
>      |
>  |

Curtis "Ovid" Poe
CTO, All Around the World
World-class software development and consulting

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About