Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz #16377
Comments
From @eserteThis is a bug report for perl from slaven@rezic.de, List-Lazy-0.3.0 does not work anymore since v5.27.7-212-g894f226e51. - The error output does not look nice. In this case it begins with Array found where operator expected at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 43, near "$$@)" which does not really say anything about the problem. Is it possible - What does this change means in terms of usability of signatures? Users BTW, the issue for the CPAN module is -- Slaven Flags: Site configuration information for perl 5.27.8: Configured by eserte at Sat Jan 20 09:22:10 CET 2018. Summary of my perl5 (revision 5 version 27 subversion 8) configuration: @INC for perl 5.27.8: Environment for perl 5.27.8: |
From @jkeenanOn Wed, 24 Jan 2018 20:04:24 GMT, slaven@rezic.de wrote:
Test failures confirmed. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @GrinnzOn Wed, Jan 24, 2018 at 3:04 PM, slaven@rezic.de <perlbug-followup@perl.org>
The alternative is signatures remaining experimental forever because -Dan |
From @xsawyerxOn 01/24/2018 09:04 PM, slaven@rezic.de wrote:
We don't like it, but the alternative is that you have partially broken Honestly, I feel this is getting ridiculous. We cannot even change |
From @AbigailOn Sat, Jan 27, 2018 at 12:21:12PM +0100, Sawyer X wrote:
That's the danger of keeping useful features experimental for a long I'd very much like to see experimental features to be time boxed: Abigail |
From @eserteDana Sat, 27 Jan 2018 03:21:32 -0800, xsawyerx@gmail.com reče:
I was just asking if it could be done better (which is probably not a good sign that I have to ask...). So that's the dilemma of experimental features: people should not use them because they can change, or vanish; but without using them possible problems get noticed too late. But I found the 1st question in the ticket more important. The now not implemented order "first signature, then attributes" seems to be the natural order for me, and it's possible that this kind of error happens often in future. So can we improve diagnostics, or even support both types of order with some safety net where the order matters (like in the case of lvalue)? |
From @xsawyerxOn 01/27/2018 01:17 PM, slaven@rezic.de via RT wrote:
Theoretically, yes. But it is assuming on foresight, which we are rarely Let's say we have two years to either determine it's stable (as now) or What we could do is provide a limit that is longer than two years, but This sits in contrast to the benefit of releasing it as experimental.
I agree it is more visually pleasing to see signatures prior to Basically, we're damned if we do and we're damned if we don't.:/ |
From @eserteDana Sat, 27 Jan 2018 06:35:49 -0800, xsawyerx@gmail.com reče:
I would like to look into this discussion, but it's difficult to find these threads... well, we really need something like a TIP or PEP process... The only thing which I see as a rationale for the change is the examples in perl5.27.8's perldelta. And the lvalue example there looks quite contrived to me.
What deadline? If there needs to be the choice between meeting a deadline and having a good language definition, I would know what to choose. Regards, |
From zefram@fysh.orgslaven@rezic.de via RT wrote:
Contentious changes freeze for 5.28. The deadline was 5.27.8. Any change -zefram |
From zefram@fysh.orgslaven@rezic.de wrote:
Mm, that's not nice. The real error is the third one emitted:
I'd be satisfied if the real error at least were the first one emitted. Simpler cases also emit the error messages in the wrong order, even if $ perl5.27.8 -Mexperimental=signatures -lwe 'sub foo ( -zefram |
From @cpansproutOn Sun, 28 Jan 2018 03:23:23 -0800, zefram@fysh.org wrote:
I don’t think a revert of a contentious change has ever been considered contentious. (I’m not saying it should be reverted; I’m just trying to clarify how this policy has thus far been applied.) -- Father Chrysostomos |
From @xsawyerxOn 01/28/2018 11:51 AM, slaven@rezic.de via RT wrote:
Agreed. One was titled "Urgent subroutine signatures problems" from December
Agreed. I wrote about such an option in a response to "We need a language design
I've had long conversations with Stevan Little about this, who pushed Considering that code was in until recently, I deem it okay to move it I'm CC'ing Stevan here and will let him make his claim.
Theoretically freeze. I tried to signal that in the email I wrote on it. |
From zefram@fysh.orgSawyer X wrote:
It would be asinine to compromise the functionality for what is at best Not only would current functionality be lost, but also a class of -zefram |
From @xsawyerxOn 02/06/2018 12:38 PM, Zefram wrote:
What I am reading here is implying that cosmetic changes are Furthermore, one could also argue that calling return from a signature It's just a wrong place to start the discussion from, IMHO. The more I
Could you expand on this? Have we ever explored this class of functionality? Where is the |
From zefram@fysh.orgSawyer X wrote:
That's not my position. Cosmetic issues are of lower importance than
No, that's not cosmetic, that's a difference in functionality. One might
Some, yes. Returning from a default value expression can be a convenient There's also more value than this in permitting returning from a
What is?
The potential that would be lost is to have attributes affect the The general concept being discussed was that we're going to make direct Another aspect of @_ suppression being discussed was what should happen There's quite a problem here in that it looks somewhat inevitable -zefram |
From @xsawyerxOn 02/06/2018 03:43 PM, Zefram wrote:
Agreed.
This functionality is equivalent to writing "return" inside the sub. (Though this does suggest that signatures themselves are cosmetic, which
I fail to imagine this being less verbose in a signature, rather than
This isn't the cost of not moving them. The cost is a narrow case of: * Using :lvalue That's it, as far as I understand.
True, but it is an edge case. Edge cases exist, especially in Perl. The
That referred to cosmetics. You can ignore it because we addressed it above.
Are there any others?
I'm sorry. I couldn't follow this.
This is also hard for me to follow. Is the summary that we would not be |
From zefram@fysh.orgSawyer X wrote:
Consider sub foo :lvalue ($a = return $p, $b = assign_default_b($a)) { versus sub foo ($a = undef, $b = undef) :lvalue { Observe that the conditions involving the presence of arguments, which
I'm not clear what you're trying to say here. You seem to be trying to
Getting the edge cases right matters. Getting them wrong means the
Er, what? Consistent with what? Signatures *after* attributes is what
Perhaps you'd do better reading the actual thread in which it arose.
Pretty much. -zefram |
From @eserteDana Wed, 24 Jan 2018 12:04:24 -0800, slaven@rezic.de reče:
Also affected: ALEXBYK/Evo-0.0405.tar.gz |
From zefram@fysh.orgI wrote:
Looking more closely, the reason why the real error isn't emitted first The reason why some other messages appear before the errors is that the All of these bits of behaviour are individually intentional, but they We can't fix this for 5.28. -zefram |
From Eirik-Berg.Hanssen@allverden.noOn Thu, Feb 15, 2018 at 8:06 PM, Zefram <zefram@fysh.org> wrote:
Naïve suggestion: On the first error, make all warnings fatal for the Eirik |
From zefram@fysh.orgEirik Berg Hanssen wrote:
That would break nested things that would incur warnings in a different -zefram |
From Eirik-Berg.Hanssen@allverden.noOn Thu, Feb 15, 2018 at 8:35 PM, Zefram <zefram@fysh.org> wrote:
Still naïve, I fear: Does it matter? This is "on the first error" and "for the duration of the queue", so what Eirik |
From @cpansproutOn Thu, 15 Feb 2018 11:35:56 -0800, zefram@fysh.org wrote:
If, when the first error is queued, we just make warnings fatal for the current compilation scope, I think it would work. You don’t have to worry about nested scopes, because BEGIN blocks will not run after an error. -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
There are plenty of ways for code to run other than BEGIN blocks. -zefram |
From @nwc10On Tue, Feb 06, 2018 at 10:38:40AM +0000, Zefram wrote:
"can't return" - which would need to be enforced? At compile time? As a hard Before the recent change (with attributes after signatures) what happened A) error at compile time (presume not, but referenced below) ? and if we wanted to go back to the other syntax order 1) what of those three we do in the case of discovering the lvalue attribute Something about all this is bothering me a lot. (And it's bothering me that I can't get it clear enough in my head to write I think that it's a combination of two things. The second comes below, and
But the first is that we're seriously proposing to (re-)add a special case. Yes, the implementation is full of them. But we should be striving to remove
And I think it very unlikely that folks are going to read the documentation, Putting attributes first (at the cost of another special case to remember) There's a Larry Wall quote/observation about this (which I can't find) to The second thing that bothers me a lot is this:
[more detail]
Effectively here with lvalues we've already got a non-theoretical use case (Due to how perl 5 compiles code to optrees as soon as it's parsed. And Zefram states another - any pragmatic implementation of @_ suppression is Any other functionality that we might want to add that involves 1) argument parsing needs to be known about before the signature is parsed, which means that I tried to think of stuff that we might want to do where they are most sub foo :inlineable { to signal that a subroutine should be inlined (where possible, and hence Likely implementing such a feature would need to compile to a different set and then likely rather hard to implement: sub foo :multimethod(Bar: $bar, Baz: $baz) { but the declaration of which arguments are part of dispatch likely can't fit (Remember, Perl 6 changes the ternary op to C<?? !!> which frees up the colon and given that the attribute has declared 2 (or more) arguments, they wouldn't For completeness, but probably not useful: sub foo :cached { a built-in Memoize equivalent. Which logically *should* wrap code in the and also possibly not useful: sub foo :method { sub foo :method(Bar: $this) { as it's more logically covered by expanding signatures to take types (if But such an attribute could prefix the subroutine's code with a check that [Sawyer]:
I'm not sure either. But there is a clear cost here of preventing a whole class of future
Particularly if we can't detect the edge cases at compile time. This one is not easy to balance either. It's already really damn hard to Nicholas Clark |
From @xsawyerxNicholas, thank you for replying in such detail. Please forgive my On 02/17/2018 12:00 PM, Nicholas Clark wrote:
You are right. I thought I had made the decision on changing the syntax
I appreciate the time and effort you took in writing this. The points Thank you, Nick, Zefram, and Yves. |
From @nwc10On Sun, Feb 18, 2018 at 11:12:01PM +0200, Sawyer X wrote:
That is really not a problem.
For some reason your choice of words made me laugh (in a good way). I think you're right to reflect on it. I'm not meaning to sound pessemistic, I suspect that a lot of this awkwardness comes from how signatures feel like Maybe I'm over-generalising, or making a false connection, but it seems like And over-over-generalising, that makes me think of If the builtin's arguments cannot be adequately expressed by a prototype C<prototype> returns the prototype. Unless it can't.
Thank you for all the time you put into this, and trying to ensure that And it was more fun than what I was doing on Sunday. (I don't know exactly Nicholas Clark |
From @iabynOn Mon, Feb 19, 2018 at 07:44:49AM +0000, Nicholas Clark wrote: The more I think about this, the more I think that attributes should This has the following advantages: 1) It allows :lvalue (and any future attributes) to be put in the 2) It allows current and future code using signatures to run on perls back In particular it will allow the relatively common idiom of 3) It doesn't need any fragile hacks like disallowing 'return' within I'm prepared to implement this if a consensus is reached (although I -- |
From @demerphqOn 21 Feb 2018 00:14, "Dave Mitchell" <davem@iabyn.com> wrote: On Mon, Feb 19, 2018 at 07:44:49AM +0000, Nicholas Clark wrote: The more I think about this, the more I think that attributes should This has the following advantages: 1) It allows :lvalue (and any future attributes) to be put in the 2) It allows current and future code using signatures to run on perls back In particular it will allow the relatively common idiom of 3) It doesn't need any fragile hacks like disallowing 'return' within I'm prepared to implement this if a consensus is reached (although I Before we say yes can you outline how one would mark an attribute as Yves |
From zefram@fysh.orgDave Mitchell wrote:
That would be a bad idea. Although it would make it possible to put Any attribute that has been classed as permitted to follow a signature Under these conditions, we couldn't really say that signatures were Relative to the present situation of having signatures after all The balancing exercise is easy: compatibility that was disclaimed can't -zefram |
From @eserteDana Fri, 09 Feb 2018 14:21:58 -0800, slaven@rezic.de reče:
Also effected (very probably): STEVAN/Moxie-0.07.tar.gz |
From @iabynOn Wed, Feb 21, 2018 at 06:56:26PM +0000, Zefram wrote:
Ok, I'm convinced (mostly). I plan to do the following two things shortly (assuming they prove 1) change the parser so that subs under 'use feature signatures' use This will then help reduce confusing errors, e.g. this code with a syntax no feature 'signatures'; currently gives: Illegal character following sigil in a subroutine signature at It's parsing the ($$@) as a sub signature even though signatures aren't in 2) For the signature sub grammar rule, allow it to spot attributes -- |
From @ribasushiOn 02/21/2018 07:56 PM, Zefram wrote:
The above statement is false. Zefram's argument over the past several months is predicated on the idea That idea is false (at best) |
From @demerphqOn 22 Feb 2018 20:11, "Peter Rabbitson" <rabbit-p5p@rabbit.us> wrote: On 02/21/2018 07:56 PM, Zefram wrote:
The above statement is false. Zefram's argument over the past several months is predicated on the idea The above statement is at best a half truth. Not only that it is an The key problem is that putting signatures before attributes means that the This point is utterly devastating to the counter-arguments that have been The additional arguments about experimental status are merely icing on the If you have something more useful to contribute that accusing a key Thanks, |
From zefram@fysh.orgPeter Rabbitson wrote:
It still seems true to me. Perhaps you could explicate what other
My argument is in no way predicated on signatures not having existed The idea that signatures have never been stable is true, unless you're My argument doesn't entirely depend on the experimental status of -zefram |
From @iabynOn Thu, Feb 22, 2018 at 10:27:18AM +0000, Dave Mitchell wrote:
I've now done this and pushed as branch smoke-me/davem/sig_attr_croak. The two important commits in that branch are: commit 07431a2 detect sub attributes following a signature commit a47e280 rationalise subroutine parsing rules -- |
From @jkeenanOn Mon, 26 Feb 2018 23:48:20 GMT, davem wrote:
I built this branch on FreeBSD-11.0, then installed 'cpanm' against it and used cpanm to try to install the three modules cited in this ticket: List::Lazy, Evo, and Moxie. Tests failed in all three with this kind of message: ##### Output of perl -V and gzipped build.log attached. Should I have expected better results? Thank you very much. -- |
From @jkeenanSummary of my perl5 (revision 5 version 27 subversion 9) configuration: Characteristics of this binary (from libperl): |
From @karenetheridgeOn Thu, Feb 22, 2018 at 9:18 AM, Zefram <zefram@fysh.org> wrote:
Well, there's https://metacpan.org/release/signatures, which has had a |
From @iabynOn Mon, Feb 26, 2018 at 05:47:04PM -0800, James E Keenan via RT wrote:
My branch addresses the main complaint of the OP, that the error message So, no, you shouldn't have expected better results. -- |
From @ilmariDave Mitchell <davem@iabyn.com> writes:
LGTM - ilmari |
From @cpansproutOn Tue, 27 Feb 2018 03:49:59 -0800, ilmari wrote:
Same here. (LGTM = Laughing goats trot merrily.) -- Father Chrysostomos |
From @iabyn
Now merged with v5.27.8-432-gbe68a30 -- |
|
@iabyn - Status changed from 'open' to 'resolved' |
From zefram@fysh.orgThe perl version numbers in the perldiag entry were slightly wrong. -zefram |
From @jkeenanOn Tue, 27 Feb 2018 06:54:17 GMT, davem wrote:
YANICK has uploaded List-Lazy-0.3.1, which now PASSes on FreeBSD-11.0. -- |
From darren@DarrenDuncan.netFor the record, I strongly support the idea that things which don't need to be Signatures and attributes should be declarable in either sequence, either one Even if something is officially experimental, that doesn't mean there isn't -- Darren Duncan |
From @xsawyerxOn 04/21/2018 09:45 PM, Darren Duncan wrote:
What are you determining this on?
The change was to revert breaking compatibility. I see people keep Keeping subroutine signatures where they were would break :lvalue |
From @LeontOn Sun, Apr 22, 2018 at 11:25 AM, Sawyer X <xsawyerx@gmail.com> wrote:
Either I'm not understanding you, or you are not understanding him. I Leon |
From @iabynOn Wed, May 02, 2018 at 08:50:45AM +0200, Leon Timmermans wrote:
I'm not aware of "the other possible solution". What is that? -- |
From @xsawyerxOn 05/02/2018 09:50 AM, Leon Timmermans wrote:
I did understand this is an argument for the option of changing the Even if something is officially experimental, that doesn't mean which I understood as "Don't break signatures even though they're I should have added that we did raise the possibility of putting I apologize for the confusion caused by my response. |
From @eserteDana Fri, 09 Feb 2018 14:21:58 -0800, slaven@rezic.de reče:
This ticket was closed, but at least this module (and possibly also others mentioned here) was not handled. |
From @iabynOn Wed, May 23, 2018 at 11:30:15PM -0700, slaven@rezic.de via RT wrote:
All affected distributions mentioned in this ticket now either pass on Evo-0.0405 -- |
p5pRT
added
BBC
Migrated from rt.perl.org#132760 (status was 'resolved')
Searchable as RT132760$
The text was updated successfully, but these errors were encountered: