Mailing List Archive: use feature 'signatures' -> s/subroutine/function/

use feature 'signatures' -> s/subroutine/function/

ilya.tk at gmail

Jan 4, 2022, 11:29 AM

Post #1 of 6 (276 views)

The documentation suggests the following experimental way to set signatures
for subroutines.

```
To declare subroutines:

sub NAME; # A "forward" declaration.
sub NAME(PROTO); # ditto, but with prototypes
sub NAME : ATTRS; # with attributes
sub NAME(PROTO) : ATTRS; # with attributes and prototypes

sub NAME BLOCK # A declaration and a definition.
sub NAME(PROTO) BLOCK # ditto, but with prototypes
sub NAME : ATTRS BLOCK # with attributes
sub NAME(PROTO) : ATTRS BLOCK # with prototypes and attributes

use feature 'signatures';
sub NAME(SIG) BLOCK # with signature
# ^ At this point, we see the intersection of syntax
sub NAME :ATTRS (SIG) BLOCK # with signature, attributesS
sub NAME :prototype(PROTO) (SIG) BLOCK # with signature, prototype
```

The parser needs to know about the lexical scoping context in order to
determine what is inside the parentheses, SIG or PROTO.
This complicates, in particular, the work of syntax highlighting in the
editor.

I propose to introduce a new keyword to avoid confusion. For example fn.

```
To declare subroutines:

sub NAME; # A "forward" declaration.
sub NAME(PROTO); # ditto, but with prototypes
sub NAME : ATTRS; # with attributes
sub NAME(PROTO) : ATTRS; # with attributes and prototypes

sub NAME BLOCK # A declaration and a definition.
sub NAME(PROTO) BLOCK # ditto, but with prototypes
sub NAME : ATTRS BLOCK # with attributes
sub NAME(PROTO) : ATTRS BLOCK # with prototypes and attributes

use feature 'signatures';
fn NAME(SIG) BLOCK # with signature
fn NAME :ATTRS (SIG) BLOCK # with signature, attributes
fn NAME :prototype(PROTO) (SIG) BLOCK # with signature, prototype
```

This is the approach used in Method::Signatures.

As a bonus, we have the opportunity in the future to get rid of the
sub(routine) designation, which smells of antiquity.
Which may affect the image of perl as a legacy development tool.

In the documentation, by the way, both designations are used.
```
$ perldoc perlsub | grep -io 'function\|subroutine' | sort | uniq -ic
70 function
148 subroutine
```

Re: use feature 'signatures' -> s/subroutine/function/ [ In reply to ]

perl.p5p at rjbs

Jan 8, 2022, 6:45 AM

Post #2 of 6 (276 views)

On Tue, Jan 4, 2022, at 2:29 PM, ???? wrote:
> I propose to introduce a new keyword to avoid confusion. For example fn.

I am opposed. Subroutines with or without signatures are not distinct things in need of distinct names.

*On the other hand*, I think Perl 5 could definitely benefit from something akin to arrow functions for anonymous signatured subroutines.

$container->each(($n) ==> { $n**2 - $n/2 })

I like "fn" better than "sub" in some ways, but it's been "sub" for decades, and I don't think the gain is worth it.

--
rjbs

Re: use feature 'signatures' -> s/subroutine/function/ [ In reply to ]

leonerd at leonerd

Jan 8, 2022, 8:45 AM

Post #3 of 6 (276 views)

On Sat, Jan 08, 2022 at 09:45:39AM -0500, Ricardo Signes wrote:
> *On the other hand*, I think Perl 5 could definitely benefit from something akin to arrow functions for anonymous signatured subroutines.
>
> $container->each(($n) ==> { $n**2 - $n/2 })

While cute, I'm not sure it really gains anything in conciseness over

$container->each(sub ($n) { $n**2 - $n/2 })

being exactly the same length.

--

Paul "LeoNerd" Evans

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

Re: use feature 'signatures' -> s/subroutine/function/ [ In reply to ]

Jan 8, 2022, 8:51 AM

Post #4 of 6 (276 views)

hello,

> I am opposed. Subroutines with or without signatures are not distinct
> things in need of distinct names.

Out of curiosity: why is it so important ? I used Method::Signatures
a lot and i understood fn was the hook for plugable keyword but i saw
a huge benefit there: it saved me from the :prototype(_) thing so
both the prototype syntax and the signature ones were short and i could
simply choose one.

sub trim (_) { ... }
fn find ($user) { ... }

to me the ideal world would be

sub trim (_) { ... }
sub find ($user) { ... }

but AFAIR, some perl hackers told me it was not that simple.

> $container->each(($n) ==> { $n**2 - $n/2 })

this would be awesome too ... even in a more rakuish way?

==> $x { $x**2 - $x/2 }

regards
marc

Re: use feature 'signatures' -> s/subroutine/function/ [ In reply to ]

perl.p5p at rjbs

Jan 8, 2022, 12:30 PM

Post #5 of 6 (276 views)

On Sat, Jan 8, 2022, at 11:51 AM, Marc Chantreux wrote:
> > I am opposed. Subroutines with or without signatures are not distinct
> > things in need of distinct names.
>
> Out of curiosity: why is it so important ?

I don't know how important you think I think it is. If you imagine that "fn" is going to change the value of Perl to its programmers, I think the change has a small absolute value. I think the negative part, which I highlight, wins out over the suggested positive change. I don't think either one is very important. But if we make a change, it should be clearly a net win. I don't think it is.

> I used Method::Signatures a lot and i understood fn was the hook for plugable keyword but i saw a huge benefit there: it saved me from the :prototype(_) thing so both the prototype syntax and the signature ones were short and i could simply choose one.

The prototype syntax should be long to discourage its casual use.

--
rjbs

Re: use feature 'signatures' -> s/subroutine/function/ [ In reply to ]

Jan 8, 2022, 1:14 PM

Post #6 of 6 (276 views)

hello Ricardo,

Thanks for your answer. it makes sense. The most enlightening part of it
to me is there:

> The prototype syntax should be long to discourage its casual use.

I had this feeling that prototypes are important to me (especially _ and
&) but if p5p doesn't feel that way: yes, the benefit of the fn keyword
is very limited.

regards,
marc