Blead Breaks CPAN: YANICK/List-Lazy-0.3.0.tar.gz

[p5pRT]

Migrated from rt.perl.org#132760 (status was 'resolved')

Searchable as RT132760$

[p5pRT]

From @eserte

This is a bug report for perl from slaven@​rezic.de,
generated with the help of perlbug 1.41 running under perl 5.27.8.

---

List-Lazy-0.3.0 does not work anymore since v5.27.7-212-g894f226e51.
This is the change which swapped signatures and attributes.
This change is already documented in perldelta, but I have just
two notes​:

- 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 "$$@​)"
  (Missing operator before @​)?)
"my" variable $step masks earlier declaration in same statement at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 44.
syntax error at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 36, near ") :"
Global symbol "$generator" requires explicit package name (did you forget to declare "my $generator"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 38.
Global symbol "$state" requires explicit package name (did you forget to declare "my $state"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 39.
Global symbol "$min" requires explicit package name (did you forget to declare "my $min"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 43.
Global symbol "$max" requires explicit package name (did you forget to declare "my $max"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 43.
Global symbol "$step" requires explicit package name (did you forget to declare "my $step"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 43.
Invalid separator character '{' in attribute list at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 44, near "$step : sub "
Global symbol "$step" requires explicit package name (did you forget to declare "my $step"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 44.
...

  which does not really say anything about the problem. Is it possible
  to detect this situation and improve diagnostics?

- What does this change means in terms of usability of signatures? Users
  mixing signatures and prototypes must increase their perl prerequisite
  from 5.22 to 5.28, which may mean it could be less likely that
  signatures are used in the next time. Is this worth for this change?

BTW, the issue for the CPAN module is
yanick/List-Lazy#3

-- Slaven

---

---

Flags​:
  category=core
  severity=low

---

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​:
 
  Platform​:
  osname=linux
  osvers=3.16.0-4-amd64
  archname=x86_64-linux
  uname='linux cabulja 3.16.0-4-amd64 #1 smp debian 3.16.51-3 (2017-12-13) x86_64 gnulinux '
  config_args='-ds -e -Dprefix=/opt/perl-5.27.8 -Dusedevel -Dusemallocwrap=no -Dcf_email=srezic@​cpan.org'
  hint=recommended
  useposix=true
  d_sigaction=define
  useithreads=undef
  usemultiplicity=undef
  use64bitint=define
  use64bitall=define
  uselongdouble=undef
  usemymalloc=n
  default_inc_excludes_dot=define
  bincompat5005=undef
  Compiler​:
  cc='cc'
  ccflags ='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2'
  optimize='-O2'
  cppflags='-fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include'
  ccversion=''
  gccversion='4.9.2'
  gccosandvers=''
  intsize=4
  longsize=8
  ptrsize=8
  doublesize=8
  byteorder=12345678
  doublekind=3
  d_longlong=define
  longlongsize=8
  d_longdbl=define
  longdblsize=16
  longdblkind=3
  ivtype='long'
  ivsize=8
  nvtype='double'
  nvsize=8
  Off_t='off_t'
  lseeksize=8
  alignbytes=8
  prototype=define
  Linker and Libraries​:
  ld='cc'
  ldflags =' -fstack-protector-strong -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib
  libs=-lpthread -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
  perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
  libc=libc-2.19.so
  so=so
  useshrplib=false
  libperl=libperl.a
  gnulibc_version='2.19'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs
  dlext=so
  d_dlsymun=undef
  ccdlflags='-Wl,-E'
  cccdlflags='-fPIC'
  lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector-strong'

---

@​INC for perl 5.27.8​:
  /opt/perl-5.27.8/lib/site_perl/5.27.8/x86_64-linux
  /opt/perl-5.27.8/lib/site_perl/5.27.8
  /opt/perl-5.27.8/lib/5.27.8/x86_64-linux
  /opt/perl-5.27.8/lib/5.27.8

---

Environment for perl 5.27.8​:
  HOME=/home/eserte
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/local/bin​:/usr/bin​:/bin​:/usr/local/sbin​:/usr/sbin​:/sbin​:/home/eserte/bin/linux-gnu​:/home/eserte/bin/sh​:/home/eserte/bin​:/home/eserte/bin/pistachio-perl/bin​:/usr/games​:/home/eserte/devel
  PERLDOC=-MPod​::Perldoc​::ToTextOverstrike
  PERL_BADLANG (unset)
  SHELL=/bin/zsh

[p5pRT]

From @jkeenan

On Wed, 24 Jan 2018 20​:04​:24 GMT, slaven@​rezic.de wrote​:

This is a bug report for perl from slaven@​rezic.de,
generated with the help of perlbug 1.41 running under perl 5.27.8.

-----------------------------------------------------------------
List-Lazy-0.3.0 does not work anymore since v5.27.7-212-g894f226e51.
This is the change which swapped signatures and attributes.
This change is already documented in perldelta, but I have just
two notes​:

- 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 "$$@​)"
(Missing operator before @​)?)
"my" variable $step masks earlier declaration in same statement at
/home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-
2/blib/lib/List/Lazy.pm line 44.
syntax error at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-
2/blib/lib/List/Lazy.pm line 36, near ") :"
Global symbol "$generator" requires explicit package name (did you
forget to declare "my $generator"?) at
/home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-
2/blib/lib/List/Lazy.pm line 38.
Global symbol "$state" requires explicit package name (did you forget
to declare "my $state"?) at /home/eserte/.cpan/build/2018012418/List-
Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 39.
Global symbol "$min" requires explicit package name (did you forget to
declare "my $min"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-
0.3.0-2/blib/lib/List/Lazy.pm line 43.
Global symbol "$max" requires explicit package name (did you forget to
declare "my $max"?) at /home/eserte/.cpan/build/2018012418/List-Lazy-
0.3.0-2/blib/lib/List/Lazy.pm line 43.
Global symbol "$step" requires explicit package name (did you forget
to declare "my $step"?) at /home/eserte/.cpan/build/2018012418/List-
Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 43.
Invalid separator character '{' in attribute list at
/home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-
2/blib/lib/List/Lazy.pm line 44, near "$step : sub "
Global symbol "$step" requires explicit package name (did you forget
to declare "my $step"?) at /home/eserte/.cpan/build/2018012418/List-
Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 44.
...

which does not really say anything about the problem. Is it possible
to detect this situation and improve diagnostics?

- What does this change means in terms of usability of signatures?
Users
mixing signatures and prototypes must increase their perl
prerequisite
from 5.22 to 5.28, which may mean it could be less likely that
signatures are used in the next time. Is this worth for this change?

BTW, the issue for the CPAN module is
yanick/List-Lazy#3

-- Slaven

Test failures confirmed.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @Grinnz

On Wed, Jan 24, 2018 at 3​:04 PM, slaven@​rezic.de <perlbug-followup@​perl.org>
wrote​:

- What does this change means in terms of usability of signatures? Users
mixing signatures and prototypes must increase their perl prerequisite
from 5.22 to 5.28, which may mean it could be less likely that
signatures are used in the next time. Is this worth for this change?

The alternative is signatures remaining experimental forever because
attributes can't work correctly with them, so the sooner this change is
made the better in my opinion.

-Dan

[p5pRT]

From @xsawyerx

On 01/24/2018 09​:04 PM, slaven@​rezic.de wrote​:

[...]

- What does this change means in terms of usability of signatures? Users
mixing signatures and prototypes must increase their perl prerequisite
from 5.22 to 5.28, which may mean it could be less likely that
signatures are used in the next time. Is this worth for this change?

We don't like it, but the alternative is that you have partially broken
signatures. If we demand that signatures stay where they are, we are
demanding they stay broken when it comes to cooperating with other,
stable syntax - namely, subroutine attributes. This is literally broken
by design, in that sense.

Honestly, I feel this is getting ridiculous. We cannot even change
experimental features that were *always* experimental because people
already started using it?

[p5pRT]

From @Abigail

On Sat, Jan 27, 2018 at 12​:21​:12PM +0100, Sawyer X wrote​:

On 01/24/2018 09​:04 PM, slaven@​rezic.de wrote​:

[...]

- What does this change means in terms of usability of signatures? Users
mixing signatures and prototypes must increase their perl prerequisite
from 5.22 to 5.28, which may mean it could be less likely that
signatures are used in the next time. Is this worth for this change?

We don't like it, but the alternative is that you have partially broken
signatures. If we demand that signatures stay where they are, we are
demanding they stay broken when it comes to cooperating with other,
stable syntax - namely, subroutine attributes. This is literally broken
by design, in that sense.

Honestly, I feel this is getting ridiculous. We cannot even change
experimental features that were *always* experimental because people
already started using it?

That's the danger of keeping useful features experimental for a long
time, specially, if they have been stable for a while.

I'd very much like to see experimental features to be time boxed​:
after say, 2 releases, either the feature is considered stable,
or it will be scratched (at least, as is).

Abigail

[p5pRT]

From @eserte

Dana Sat, 27 Jan 2018 03​:21​:32 -0800, xsawyerx@​gmail.com reče​:

On 01/24/2018 09​:04 PM, slaven@​rezic.de wrote​:

[...]

- What does this change means in terms of usability of signatures? Users
mixing signatures and prototypes must increase their perl prerequisite
from 5.22 to 5.28, which may mean it could be less likely that
signatures are used in the next time. Is this worth for this change?

We don't like it, but the alternative is that you have partially broken
signatures. If we demand that signatures stay where they are, we are
demanding they stay broken when it comes to cooperating with other,
stable syntax - namely, subroutine attributes. This is literally broken
by design, in that sense.

Honestly, I feel this is getting ridiculous. We cannot even change
experimental features that were *always* experimental because people
already started using it?

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)?

[p5pRT]

From @xsawyerx

On 01/27/2018 01​:17 PM, slaven@​rezic.de via RT wrote​:

Dana Sat, 27 Jan 2018 03​:21​:32 -0800, xsawyerx@​gmail.com reče​:

On 01/24/2018 09​:04 PM, slaven@​rezic.de wrote​:

[...]

- What does this change means in terms of usability of signatures? Users
mixing signatures and prototypes must increase their perl prerequisite
from 5.22 to 5.28, which may mean it could be less likely that
signatures are used in the next time. Is this worth for this change?
We don't like it, but the alternative is that you have partially broken
signatures. If we demand that signatures stay where they are, we are
demanding they stay broken when it comes to cooperating with other,
stable syntax - namely, subroutine attributes. This is literally broken
by design, in that sense.

Honestly, I feel this is getting ridiculous. We cannot even change
experimental features that were *always* experimental because people
already started using it?
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.

Theoretically, yes. But it is assuming on foresight, which we are rarely
privileged to. Abigail's idea of a two-year limit to experimental could
help, but we already use two-year to determine that it's stable.

Let's say we have two years to either determine it's stable (as now) or
remove the feature (per suggestion). One year in, we realize there's a
certain limitation we can fix. Should we fix it? We can't. If we fix it,
we go above the two year limitation for removal. This can keep going, as
in the case of subroutine signatures, where we keep finding something.
The problem is that every time we assume it really is the last. For
example, in this case, we don't want to change subroutine signatures,
just their location. As a structure, they're actually stable. Their
location, however, is problematic.

What we could do is provide a limit that is longer than two years, but
we then limit ourselves to how much we can fix. We have to find all the
problems within a certain time or the feature is gone.

This sits in contrast to the benefit of releasing it as experimental.
Unless we allow it to be used, many errors will not be discovered. The
more it is out there, the more likely we are to be able to spot the
problems.

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)?

I agree it is more visually pleasing to see signatures prior to
attributes. However, that breaks. We had several threads in which I
provided two options for allowing it to work but both provided a hairy,
fragile solution. I did not provide an answer to your first question
because I don't think I have a good answer other than what we had
already discussed. I have also expressed the urgency of these and by now
we have passed the deadline on this change. If we were to find a
solution and change it once again, we would hit your second question
again - something that worked a certain way as experimental now has to
change.

Basically, we're damned if we do and we're damned if we don't.​:/

[p5pRT]

From @eserte

Dana Sat, 27 Jan 2018 06​:35​:49 -0800, xsawyerx@​gmail.com reče​:

On 01/27/2018 01​:17 PM, slaven@​rezic.de via RT wrote​:
[...]

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)?

I agree it is more visually pleasing to see signatures prior to
attributes. However, that breaks. We had several threads in which I
provided two options for allowing it to work but both provided a
hairy,
fragile solution.

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.

I did not provide an answer to your first question
because I don't think I have a good answer other than what we had
already discussed. I have also expressed the urgency of these and by
now
we have passed the deadline on this change.

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,
  Slaven

[p5pRT]

From zefram@fysh.org

slaven@​rezic.de via RT wrote​:

What deadline?

Contentious changes freeze for 5.28. The deadline was 5.27.8. Any change
to this aspect of signatures is bound to be controversial, so now it
can't be changed again until 5.29.

-zefram

[p5pRT]

From zefram@fysh.org

slaven@​rezic.de wrote​:

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 "$$@​)"
(Missing operator before @​)?)

Mm, that's not nice. The real error is the third one emitted​:

syntax error at /home/eserte/.cpan/build/2018012418/List-Lazy-0.3.0-2/blib/lib/List/Lazy.pm line 36, near ") :"

I'd be satisfied if the real error at least were the first one emitted.
It is not surprising that other errors arise following the syntax error,
but it is annoying that they would be emitted earlier. It is also
potentially misleading that the first one emitted is actually concerned
with a different sub from the one that incurs the real first error.
Clearly there's an interaction here between parser error recovery and
the statefulness of the tokeniser.

Simpler cases also emit the error messages in the wrong order, even if
not as wildly off track as in the module​:

$ perl5.27.8 -Mexperimental=signatures -lwe 'sub foo ($a) :prototype($$@​) {}'
Array found where operator expected at -e line 1, near "$$@​)"
  (Missing operator before @​)?)
  syntax error at -e line 1, near ") :"
  Execution of -e aborted due to compilation errors.

-zefram

[p5pRT]

From @cpansprout

On Sun, 28 Jan 2018 03​:23​:23 -0800, zefram@​fysh.org wrote​:

slaven@​rezic.de via RT wrote​:

What deadline?

Contentious changes freeze for 5.28. The deadline was 5.27.8. Any change
to this aspect of signatures is bound to be controversial, so now it
can't be changed again until 5.29.

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

[p5pRT]

From @xsawyerx

On 01/28/2018 11​:51 AM, slaven@​rezic.de via RT wrote​:

Dana Sat, 27 Jan 2018 06​:35​:49 -0800, xsawyerx@​gmail.com reče​:

On 01/27/2018 01​:17 PM, slaven@​rezic.de via RT wrote​:
[...]

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)?
I agree it is more visually pleasing to see signatures prior to
attributes. However, that breaks. We had several threads in which I
provided two options for allowing it to work but both provided a
hairy,
fragile solution.
I would like to look into this discussion, but it's difficult to find these threads...

Agreed.

One was titled "Urgent subroutine signatures problems" from December
13th. Zefram noted this in RT #132141 on September 21st.

well, we really need something like a TIP or PEP process...

Agreed.

I wrote about such an option in a response to "We need a language design
process." on January 1st of this year.

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.

I've had long conversations with Stevan Little about this, who pushed
that there is basically only one use that breaks​: lvalue (which is a
core subroutine attribute) with a signature that calls "return" in the
signature. On the other hand, the syntax with signatures following
attributes is quite unfriendly and can also confuse easily with
Catalyst. It might actually be better to bite the bullet on this and say
"Okay, this one case really doesn't work. If you're using lvalue
subroutine attribute, you can't return in the signature." and leave it
as the much nicer syntax.

Considering that code was in until recently, I deem it okay to move it
back one development version after. However, I will not accept this if
there is just one person (Stevan) suggesting it. I would like further
comments from others - like yourself, providing feedback on it.

I'm CC'ing Stevan here and will let him make his claim.

I did not provide an answer to your first question
because I don't think I have a good answer other than what we had
already discussed. I have also expressed the urgency of these and by
now
we have passed the deadline on this change.
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.

Theoretically freeze. I tried to signal that in the email I wrote on it.
However, in this case we have a bit of leeway moving back, as explained
above.

[p5pRT]

From zefram@fysh.org

Sawyer X wrote​:

     It might actually be better to bite the bullet on this and say

"Okay, this one case really doesn't work. If you're using lvalue
subroutine attribute, you can't return in the signature." and leave it
as the much nicer syntax.

It would be asinine to compromise the functionality for what is at best
a cosmetic improvement. (Personally I find it cosmetically neutral,
so don't agree on it being an improvement in that manner, but even
the people arguing for it don't ascribe it any more than cosmetic
value.) People have decided that the cosmetics trump grammatical and
structural coherence, but surely the line must be drawn before tangible
functionality.

Not only would current functionality be lost, but also a class of
potential functionality that we're likely to want to explore. This is
not an insignificant cost, and, as with the lvalue issue, was not taken
into account in the decision to move signatures to precede attributes,
because it wasn't specifically noticed at the time. (I eventually
identified it in the @​_-suppression thread.)

-zefram

[p5pRT]

From @xsawyerx

On 02/06/2018 12​:38 PM, Zefram wrote​:

Sawyer X wrote​:

     It might actually be better to bite the bullet on this and say

"Okay, this one case really doesn't work. If you're using lvalue
subroutine attribute, you can't return in the signature." and leave it
as the much nicer syntax.
It would be asinine to compromise the functionality for what is at best
a cosmetic improvement. (Personally I find it cosmetically neutral,
so don't agree on it being an improvement in that manner, but even
the people arguing for it don't ascribe it any more than cosmetic
value.) People have decided that the cosmetics trump grammatical and
structural coherence, but surely the line must be drawn before tangible
functionality.

What I am reading here is implying that cosmetic changes are
meaningless. Take into account how Catalyst breaks differently if
someone were to introduce a space, from "​:CaptureArgs(...)" to
"​:CaptureArgs (...)". This is cosmetic but will now result in a
completely different error (if at all), which could be quite confusing
to the user. We care about that.

Furthermore, one could also argue that calling return from a signature
serves little purpose and is also a cosmetic difference and is possibly
equally meaningless. Is there any value in returning from a signature
(especially when using :lvalue) which cannot be just as easily
ascertained without?

It's just a wrong place to start the discussion from, IMHO. The more I
spoke with Stevan about this, the more I realized this needs more
thought. I wish more people joined the conversation.

Not only would current functionality be lost, but also a class of
potential functionality that we're likely to want to explore.

Could you expand on this?

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