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

Re: For 5.24: suggested incompatible changes

Thread Previous | Thread Next
Aristotle Pagaltzis
June 28, 2015 14:06
Re: For 5.24: suggested incompatible changes
Message ID:
* Zefram <> [2015-06-27 13:40]:
> it would be nice to reduce the massive confusion people have between
> signatures and prototypes.

Maybe someday we can add a default warning for subs outside the scope of
the signatures feature which use the shorthand non-:prototype() form of
prototypes. (Years down the line from non-experimental signatures, if

> Generally, prototypes are quite unpopular, so making them happen by
> default would go down badly. (I think their unpopularity is unfair: it
> seems to stem from some backlash at them not being signatures.)

No. It stems from prototypes disabling list flattening, which is one of
the most fundamental design choices of Perl 5. With prototypes that do
anything, the otherwise largely pervasive principle that you can use
@foo in place of ($foo, $bar) gets broken. So prototypes sit at odds
with the rest of the language.

Their involvement means you cannot understand a function call just by
looking at it; you have to look up the prototype to understand how the
call will parse and what values will be passed. More importantly, you
can no longer *write* calls without knowing the prototype.

Prototypes are also severely limited in whatever usefulness they might
have by the fact that method calls cannot respect prototypes, only
function calls, which of course is because prototypes change the parsing
so they have to be resolved at compile time. That is to say, they need
to change the rules by which the language would usually work, which is
just another way of saying that they sit at odds with the rest of the

The only prototypes I consider at all sane to use are () and (&@), and
the latter isn’t sane so much as too useful to throw away entirely. If
there were a generalised way of achieving the same thing as part of the
regular language, rather than having to introduce it through the side
door using a prototype, I would immediately stop using that prototype
too, and a variety of APIs I’ve created or seen could immediately become
better, because the bare block syntax would then be available in method
calls as well as function calls.

> It is indeed a priori silly that the () prototype is a prerequisite
> for the built-in sub constant folding, but the constant folding
> is semantically visible, so we can't go arbitrarily changing it.
> An explicit :fold attribute might be a better way forward.

Isn’t that what :const is?

Aristotle Pagaltzis // <>

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