Skip to content

SC Notes 2020 07 14

Jump to bottom
James E Keenan edited this page Jul 21, 2020 · 5 revisions

Arrangements

Date: 2020-07-14 19:00 GMT Location: Zoom

Attendees

Meeting notes

Meeting objectives

  • How to Perl 7
  • Opening Blead.

How to Perl 7

Initial discussion

  • Sawyer summarized points. Would like us to discuss the original plan first.
    • Perl 7 would have new defaults and a way to switch back to perl 5 defaults if needed.
    • John pointed out that no other scripting language with a new major version required an invocation to run it in the new mode.
  • A major version has expectation of level of breakage. It's ok to run both the old and the new.
  • Paul discussed his idea for scoping new code in a class {} or module {} block.
    • There was a concern that this solved the problem for 7 but didn't for 8, 9, 10, etc.
    • Q: How is this different from use v7? A: It isn't and we might want that too.
  • Classes of issues
    • Software developers
    • Distributions
  • Paul: There is no argument to use v7. There is concern that v7 by default will break the majority of CPAN.

Many of the potential plans for 7 can be seen here.

After much back and forth we decided to discuss what we did and didn't have consensus on at this point.

What do we agree on?

  • There should be a perl 7 version bump
  • Very little perl code should break in 7.
    • Code which has already been written with use strict; use warnings; should rarely break.
  • Bug for bug compatibility can't continue indefinitely; breakage of some sort will be required
  • A means to get some of the older semantics on demand should exist

What do we disagree on?

  • What the defaults should be for a perl 7 program.
    • Should it imply v5 or v7 syntax by default?
  • Whether "use version" should be mandatory (currently it is optional) on any file or the interpreter dies
  • Whether we should release a perl-5.34, etc.
    • Whether new functionality can be added to Perl 5.
    • If Perl 5 should be in maintenance mode for a long time - no more features added to 5

Conclusion:

Towards the end we realized that the main sticking point was an assumption that the new defaults would break the majority of old code. However we had not yet even discussed or decided what the new defaults would be. How could we know what would break without even first defining this list and testing it?

The planned meeting terminated and some had to leave. Those that remained discussed each of the possible features to enable and reached consensus on what might be on by default in Perl 7. We agreed that without testing, we could not be certain that our assumptions that this would break very little were true.

What should perl 7 defaults be?

Features not experimental anymore

  1. current_sub
  2. postderef
  3. postderef_qq
  4. signatures
  5. lexical_sub

On by default

  1. use strict;
  2. use warnings;
    • We have some concern about runtime warnings breaking production code.
    • Are there warnings we should turn off by default?
    • Only one person present felt warnings should be off in production code but also acknowledged that the preference of most was to leave it on.
  3. feature refaliasing
my \$x = \$y;
my \%hash = $hashref;  $hash{key} eq $hashref->{key}
foreach my \%inner (@list_of_hashrefs) {
    print "$inner{thing}"
}

New keywords on by default.

  1. feature state
  2. feature evalbytes
  3. feature say
    • There is evidence it's going to break a little bit on CPAN.
    • This is a highly desired feature so the value outweighs the breaks.
  4. feature fc
    • it's a short keyword and might conflict with subroutines.
  5. feature current_sub
    • Technically this is a keyword __SUB__() -- Sawyer

Not to be included

  1. use re 'strict'
    • Could break a big chunk of CPAN.
    • Compile time errors?
    • Low confidence we would have a way to test if the code would break.
  2. feature postderef_qq
    • This might break existing stuff without warning. How could we determine the scope of risk?
  3. feature declared_refs
    • Of the people on the call, there was confusion on this item and refaliasing.
    • The docs seemed to be limited. We think they should be improved.
  4. feature bitwise
  5. feature isa
    • Too new
  6. no indirect
    • Too new
    • Initial testing shows a high amount of breakage on CPAN.
    • Should this be a warning first?
  7. feature signatures
    • Poor compatibility with old prototypes.
  8. use utf8 ($^H |= 0x00800000;)
    • This setting is currently well known to be very disruptive to several major code bases.
  9. feature switch
    • In its current state we are very unhappy with it.
  10. unicode_strings / unicode_eval

We discussed many of the not included features. Many discussions were cut short for time but the agreement was that the fact we were not enabling these by default in 7 indicated areas of discussion AFTER 7.0.0 was released.

  • Should we warn on new keyword conflicts with sub declarations?
  • How do we manage prototypes on CPAN which require :prototype($$$) and thus 5.18 in order to be compatible with subroutine signatures?
  • no indirect breaks much of CPAN. How can we encourage it to be used less? Is it safe to deprecate and drop support in 8.0?

Devel:: PPPort, PERL_VERSION, PERL_REVISION

Much of EU had worn out and signed out at this point but a few stayed behind to discuss some basic CPAN testing that had shown some big problems with Devel:: PPPort related to versions.

Many XS modules (1107 on CPAN) use ppport.h which is generated by Devel:: PPPort. The biggest problem here is that all versions of this module produce a ppport.h which fail when PERL_REVISION != 5.

Issue 1: Just like Module::Install, it is problematic that ppport.h ships with these modules. It means when a fix is applied to the header, ALL modules have to be updated to support it. It would be better if the modules somehow used ppport.h provided by a central Devel::Ppport, located in one place.

Issue 2: Almost any logic in XS which checks PERL_REVISION or PERL_VERSION is wrong as of Perl 7. It would break less stuff if these #defines were permanently set at 5 and 7000. perl ppport.h could also warn that you should not be using them and encourage the use of the coming check macros PERL_VERSION_GT(5,7,2), PERL_VERSION_LT(5,7,2), etc.

There was agreement that no matter what happens, this problem needs to be worked on and nothing blocks it from being worked on immediately. Karl, Nico, and Paul plan to reach out to some other folks to get a working group looking more closely at the problem.

In the coming week, we are hoping to

  1. Do some testing with the proposed non-controversial defaults.
    • Ensure that it doesn't cause any issues in more than a tiny handful of oddball cases
    • Work out what mitigation we can put in place around them.
  2. Form a working group on D:PPP / PERL_VERSION and try to come up with the best solution for Perl 7.
  3. Attempt to communicate the current progress to Perl 5 Porters.

Next meeting agenda (tentative)

  • Working group report on Devel::PPPort / XS for Perl 7.
  • Governance review - voting process, quorum
  • Appointment of secretary to manage arrangements, agenda & minutes
  • Revisit the features list defaults.
    • Does anyone have numbers on how the working list of defaults held up to CPAN testing?
  • How to disable things and return to v5 defaults when needed.
    • use p5
    • use v5 (magical v5.0.0 bundle in perl 7?)
      • Perhaps we should overload use v with less things not more.
    • use compat::perl5;
  • discuss the v7 feature bundle
    • Assuming a short major life cycle, should there be a 7.2 bundle or just a 7 bundle?
    • how does one do use v8 in perl 7? Many don't like v8.
      • Essentially turns on all feature guards which are planned for 8.
      • Gives people a preview mode for 8 so they can test.
      • Configure option when building perl?
      • Environment variable?
      • use cool::stuff?
  • -e / -E discussion
    • Should -E default to v7? v8?
    • Most people think -e default to v5 and much code has built up around this.
    • perl -$letter is in short supply.
    • A reminder: /usr/bin/perl7 doesn't have to be the same thing as /usr/bin/perl5
  • Difference between experimental and feature. Do we still need both?

Future agenda points

  • Jim: proposal for future release process
    • How can this change in future, be more flexible
    • Has created proposal document.
  • Todd: Discuss governance and get details fleshed out for https://github.com/Perl/perl5/wiki/Perl-Steering-Committee
  • Nico: features for perl 8 we can start warning about conflicts in v7
    • This shouldn't happen until after 7.0.0 is out.
  • Paul: Work out the "dual-life" policy for going forward
  • Paul: General "code cleanup" sessions

https://metacpan.org/release/perl

Clone this wiki locally