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
Sawyer X
February 8, 2018 10:52
Re: [perl #132760] Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz
Message ID:

On 02/06/2018 03:43 PM, Zefram wrote:
> Sawyer X wrote:
>> What I am reading here is implying that cosmetic changes are
>> meaningless.
> 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.

This functionality is equivalent to writing "return" inside the sub.

(Though this does suggest that signatures themselves are cosmetic, which
in a way, they are.)

>>                     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.

I fail to imagine this being less verbose in a signature, rather than
the subroutine body.

> 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.

This isn't the cost of not moving them. The cost is a narrow case of:

* Using :lvalue
* Using return in the subroutine

That's it, as far as I understand.

> 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.

True, but it is an edge case. Edge cases exist, especially in Perl. The
question is, how much of an edge it is, how valuable it is to have it
vs. having signatures that are more visually consistent and can provide
better output on a mistake for attributes that contain spaces.

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

That referred to cosmetics. You can ignore it because we addressed it above.

>> 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.

Are there any others?

> 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.

I'm sorry. I couldn't follow this.

> 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.

This is also hard for me to follow. Is the summary that we would not be
able to make direct references @_ that appear in the body of an
@_-suppressed body an error?

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