develooper Front page | perl.perl5.porters | Postings from February 2018

Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz

Thread Previous | Thread Next
February 6, 2018 13:43
Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz
Message ID:
Sawyer X wrote:
>What I am reading here is implying that cosmetic changes are

That's not my position.  Cosmetic issues are of lower importance than
functionality and coherence, but are not entirely devoid of value.

>Furthermore, one could also argue that calling return from a signature
>serves little purpose and is also a cosmetic difference

No, that's not cosmetic, that's a difference in functionality.  One might
still argue that it serves little purpose, of course.  But that argument
is about behaviour, not aesthetics.

>                     Is there any value in returning from a signature

Some, yes.  Returning from a default value expression can be a convenient
way to make a subroutine do different jobs depending on the arguments
supplied to it.  In non-signature-using Perl it's common enough to
see constructs along the lines of "defined $foo or return $blah".
Compared to putting this logic in the body block after the signature,
having it in the signature will at times be beneficial in a number of
ways.  Firstly, it is likely to group related concerns.  If there are
other non-trivial default expressions then it may also be important to
return before executing the next default expression, and putting all of
that logic into the body block would involve quite a lot more verbiage.
If default value expressions have to be moved into the body block then
we also run into the issue of parameter predicates: currently they're
not available as part of the signature system, and some people are
arguing against them ever being so, so this might force ugly use of @_
(or incorrect use of defined()) alongside the signature.

There's also more value than this in permitting returning from a
signature.  Perl benefits from the popular pardigm of interchangeability
of expressions, that any expression can go anywhere that an expression
is permitted.  A return expression is a type of expression, and it
doesn't take any verbiage to explain, or neurons to remember, that it is
permitted inside a while() condition, or in a sub parameter expression,
or in any other particular place that takes an expression.  But if it's
not permitted in a default value expression in a signature, that's an
exception to the general rule, which does need to be specially explained
in the documentation, and does need to be specially remembered by users,
to explain why their program doesn't work on the rare occasion that the
nature of a subroutine leads them to put this type of expression in that
type of expression slot.

>It's just a wrong place to start the discussion from, IMHO.

What is?

>Have we ever explored this class of functionality? Where is the
>likeliness coming from?

The potential that would be lost is to have attributes affect the
compilation of a subroutine's body code.  The :lvalue attribute is an
instance of that kind of functionality.  Another likely instance of it
came up in one of the threads about @_ suppression.

The general concept being discussed was that we're going to make direct
use of @_ obsolete, through signatures and maybe other features, so it
would be nice for performance if we could suppress the construction of
the dynamic @_ on subs that don't need it.  The starting point for the
discussion was the idea of tying this suppression to signature syntax
per se, either to its enablement or to actual signatures, but we wisely
decided against that.  Among control mechanisms discussed was the fairly
obvious possibility of a subroutine attribute offering explicit control
of @_ setup for a specific subroutine.  This in itself doesn't pose an
ordering problem.

Another aspect of @_ suppression being discussed was what should happen
to direct references to @_ that appear in the body of an @_-suppressed
subroutine, and one of the main options was that this should be an error.
For it to be an error requires that the @_ status of a subroutine be
known before any of its body code is compiled, and in the absence of
signatures this would be entirely compatible with attribute control.
But with signatures coming before attributes, some body code that might
refer to @_ would be compiled before the @_ status of the subroutine
is determined.  Any option for @_ suppression that affects how direct
references to @_ compile is incompatible with control by an attribute
if the attribute would appear after a signature.

There's quite a problem here in that it looks somewhat inevitable
for there to be some kind of per-sub control over @_ suppression.
Lexical flags can set defaults, but there's always going to be
the occasional exception.  What we find here is that if subroutine
attributes preceding the body didn't exist then it would be necessary
to invent them.  Currently we have them, but if they are abolished again
by moving signatures in front of attributes again then this would create
some design pressure to invent something new that does a similar job to
attributes but appears before a signature.


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