Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?

by haukex (Archbishop)
on Oct 14, 2019 at 14:06 UTC ( [id://11107415]=perlmeditation: print w/replies, xml ) Need Help??

Disclaimer: This post is entirely hypothetical. No decisions regarding Perl 5 have been made, or to my knowledge even been seriously discussed. It's entirely possible that Perl 5 will stay Perl 5 forever, or that the "5" will simply be dropped from the numbering (which would mean the next release of Perl is Perl 32), or something else happens.

Now that Perl 6 has been renamed to Raku, that theoretically leaves open the possibility of Perl 5 upgrading to Perl 7. I've thought about what features would warrant a major version number change, and that's what I'm writing about here. My list is probably not complete, and I might update it if I think of more.

First off, in my opinion, Perl should continue its tradition of being mostly backwards-compatible from release to release. If you want radical changes to the language, see Raku (and define your own slang) ;-)

  • Subroutine signatures need to come out of experimental
  • Smart matching should either be revamped, or removed entirely (Update: and if the latter, keep given as a topicalizer whose block can return a value)
  • Various other experiments should come out of experimental - e.g. refaliasing and declared_refs are IMHO pretty useful.
  • I'm not sure how this would be best implemented, but a "batteries included" Perl release would be nice. For example, one that includes Moo and other extremely common modules such as DBI. We might look to Strawberry Perl for an initial list.
  • Update 2019-11-17: Implicit use utf8; and STDIN, STDOUT, etc. default to UTF-8 as well.

I imagine that, similar to Perl 6, a Perl 7 binary might be called perl7, with files being called .p7 or .pl7, .pm7, etc. Using this interpreter or this file extension would be the same as a use v7; (and turn on the corresponding feature bundle, etc.).

Again, these are just hypothetical and unfinished thoughts of mine :-)

Update: I accidentally created this post too early, sorry for all the additional edits. I'm done for now and further significant edits will be marked as such.

Replies are listed 'Best First'.
Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by Corion (Patriarch) on Oct 14, 2019 at 14:13 UTC

    Why switch from 5 zto 7 when we can switch to Perl 32, much like Java did?

    But the one feature I'm really excited about are formal subroutine parameters, "signatures". I hope having proper signatures also removes some of the need for Moo, as much of my use case for Moo is fancy parameter parsing and setting up defaults for values.

    I see two avenues for a "batteries included" Perl, either port http://strawberryperl.com to other platforms, or have a module Perl::BatteriesIncluded, which pulls in the rest. Nobody has taken up the work involved in either one though, so either there is no such need or it is hard work. Maybe a start could be a Debian package that just lists the packages that Strawberry Perl includes as prerequisites.

      Why switch from 5 zto 7 when we can switch to Perl 32, much like Java did?

      Perl 32 sounds like Perl for old 32-bit processors. "Where is the 64 bit Perl edition?"

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        Perl 32 sounds like Perl for old 32-bit processors

        If I had seen this back in 2019 I would have suggested that it won't be long before Perl passes through the magic number 32...of course, now it has and this is no longer a concern.

      Why switch from 5 zto 7 when we can switch to Perl 32, much like Java did?

      Sure, that's a possibility. I guess my post is more about the features than the version numbering. OTOH, many versioning schemes will only switch major version numbers for major features, and so I was thinking the other way around: if Perl 5 wanted to go to Perl 7, what features would warrant that? As kind of a motivation to get those features out of experimental status :-)

      As for the "batteries included", I think a Perl::BatteriesIncluded module is a nice idea. Although I included that point somewhat reluctantly, since of course people will have different ideas for what their favorite bundle is, I think that giving new users of the language a set of proven modules to start with is a good idea. ("What do you mean, I have to download and install a bunch of modules just to do OO?") I.e. for newbies, TIMTOWTDIBSCINABTE...

      I don't get why you dislike Moo, but anyway have you tried Method::Signatures for signatures including named params, and constraints? It's quite powerful.


      The way forward always starts with a minimal test.

        I don't dislike Moo in the general sense, but more my (and my perceived) use of it, as it leads often to craete glorified hashes. Most of what Moo faciliates is in the constructor, and most of the tooling of Moo is for creating fancy helpers for constructors. If Perl had "better" parameter parsing, I can imagine Moo not being necessary, especially as Moo creates an accessor for everything even if what I really wanted was a named parameter in the constructor.

        Tadeusz put this into words far better than I can in How Moose Made Me a Bad OO Programmer.

      I really like the sound of including the real version number instead of a "5" (or "7") in the name. This way would be much easier to show progress and that it's "the latest, greatest version"
      perl -e 'use MIME::Base64; print decode_base64("4pmsIE5ldmVyIGdvbm5hIGdpdmUgeW91IHVwCiAgTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duLi4uIOKZqwo=");'
Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by LanX (Saint) on Oct 14, 2019 at 15:39 UTC
    Long time ago I've listed some ideas in my LanX's scratchpad (Things I miss in perl5).

    Basically new features should address some problems in

    • convenience,
    • orthogonality
    • acceptance
    • maintainability
    IMHO
    • Signatures must support named arguments and allow introspection.
    In combination with here docs an automatic creation of POD would be possible.
    • Autoboxing could simplify convoluted syntax!
    e.g writing

    $nested{hash}[0]->push("value")

    is far more readable than

    push @{ $nested{hash}[0] }, "value"

    • benefiting from previous analysis
    The irony is that Perl6 was preceded with a long analysis of Perl5's weaknesses. Looking up that discussions and stealing ideas would be worth it.

    • clear vision
    There are also varying perceptions of Perl5 in the community, which I tried to address in my talk about "The Camel Paradox".

    This needs to be resolved to have more productive discussions.

    For instance a good REPL/One-liner language is taking profit from special variables.

    In a large professional multi-dev/multi-module environment you prefer a more streamlined syntax.

    This could be solved by pragmas and translation tools. All these changes should be partnered with an easily understood "vision" / "business model" building faith in Perl.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by Laurent_R (Canon) on Oct 16, 2019 at 13:53 UTC
Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by ikegami (Patriarch) on Oct 19, 2019 at 13:45 UTC

    which would mean the next release of Perl is Perl 32

    The next version of Perl will indeed be version 32.

    $ perl -v | grep '^This is' This is perl 5, version 30, subversion 0 (v5.30.0) built for x86_64-li +nux-thread-multi

    So going from Perl 5 to Perl 7 wouldn't be a "major version change", it would be a language name change.

      The next version of Perl will indeed be version 32.

      $ perl -v | grep '^This is' This is perl 5, version 30, subversion 0 (v5.30.0) built for x86_64-li +nux-thread-multi

      So going from Perl 5 to Perl 7 wouldn't be a "major version change", it would be a language name change.

      If that was the case, I would expect to find something like this in the perl sources:

      printf( "This is perl 5, version %d, subversion %d (v5.%d.%d), built for % +s\n", perlmajor, perlminor, perlmajor, perlminor, perlarch );

      Searching for "This is perl" returns only a single C source file, with only one matching line: perl.c, currently around line 3768:

      PerlIO_printf(PIO_stdout, "\nThis is perl " STRINGIFY(PERL_REVISION) ", version " STRINGIFY(PERL_VERSION) ", subversion " STRINGIFY(PERL_SUBVERSION) " (%" SVf ") built for " ARCHNAME, SVfARG(level +) );

      Getting a git blame on that line shows that the last change was ded326e4b6fad7e2479796691d0c27b89d2fe080 in 2009, for v5.11, changing the format. The diff shows how the version was previously:

      PerlIO_printf(PerlIO_stdout(), "\nThis is perl, %"SVf " built for " ARCHNAME, level);

      So at least until 2009, the "5" in perl 5 was still part of the interpreter version number, and not part of the language name, at least technically. The commit comment explains the change:

      The rationale for this change is that the Perl 5 interpreter will never increment PERL_REVISION from 5 to 6, so we want people to start focusing on the PERL_VERSION number as most significant and PERL_SUBVERSION as equivalent to a "release number". In other words, "perl 5" is a language, this is the 11th version of it, and the second release of that version (counting from zero). Among other things, this makes the output of -v and -V more consistent.

      Unfortunately, the "blame" link on that page results in a broken document due to a server error while rendering the document:

      500 - Internal Server Error Malformed UTF-8 character (fatal) at /var/www/git/gitweb.cgi line 1601 +, <$fd> line 107.

      (This is visible only in the source view, Firefox complains about invalid XML.)

      So I simply looked in perl 5.000, at perl.c. Line 966 writes out the version:

      printf("\nThis is perl, version %s\n\n",patchlevel);

      Here, the name of the language was clearly "perl", not "perl 5", and the interpreter version number started with "5". So, at some point in time between 1994 and 2009, the marketing of perl changed.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

        Yes, of course "5" used to be part of the version. See perlhist. The change in convention was surely brought upon by Perl 6.

      > The next version of Perl will indeed be version 32.

      and not subversive!

      > subversion 0

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by Your Mother (Archbishop) on Oct 25, 2019 at 16:23 UTC

    Alternative take: I am not smart skilled enough to know what I really want. I’m not a language designer. I could put together a long wishlist and it might well end up as a language I hated to use because it would lack integrity and internal consistency. For all the guff Perl gets about some design choices, like $stuff[1], I think its design is subversively brilliant and partly counter intuitive. I’ve told my tale often: I started “hacking” at 10 or 11 and fell completely away from it a few years later for more than a decade. I never would have come back without Perl because only Perl made it fun.

    I do know that environment, ecology is crucial. If it is not easier in the future to create, test, build, vet, and distribute “CPAN” packages than it is today, that’s lead in a swimmer’s pockets. I don’t know how relevant that can be to language changes but I feel like it should be a concern deeper than vanilla backwards-compatibility. Personally, I have had a rough go trying to integrate C-libs into code. I would love for that to be easy. I’d settle for less difficult. That relates directly to catching up the CPAN. There are a lot of mid-level JAPHs like me that would be wrapping up modern libraries regularly.

      Have you tried FFI::Platypus to integrate C-libs? It's much simpler than XS and Inline::C for the same task.

      (I should add the caveat that I don't wrap C-libs myself, but do use and hack FFI based libs).

        I remember hearing about it and forgot to check it out. Thank you much for suggesting it again.

Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by cavac (Parson) on Oct 18, 2019 at 09:25 UTC

    DBI would be a nice core module for me. Pretty much all of my installations need it anyway. Also nice would be the default inclusion of CPAN::SQLite.

    perl -e 'use MIME::Base64; print decode_base64("4pmsIE5ldmVyIGdvbm5hIGdpdmUgeW91IHVwCiAgTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duLi4uIOKZqwo=");'

      Yes, I prefer the 'batteries included' model. It's too much of a pain to get CPAN + dependencies into our network or on the server we need it on. It is faster to just learn whatever language has it already enough to do what is needed. We've even.. used powershell. Although, if it is in the Red Hat repository it's not too much trouble to install it. But then it goes to your 'OS Version', which I think is essentially not the ideal way to think about software. I'm hoping RHEL8 fixes it with the concept of appstreams.

Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by cavac (Parson) on Oct 22, 2019 at 08:38 UTC

    As for "incompatible" changes, the next/new/improved/whatever Perl should just go ahead and activate strict (and warnings?) by default. Besides improving overall code quality, it would probably reduce the number of SoPW questions. It would also make Perl easier to learn since it removes a lot of silent pitfalls.

    perl -e 'use MIME::Base64; print decode_base64("4pmsIE5ldmVyIGdvbm5hIGdpdmUgeW91IHVwCiAgTmV2ZXIgZ29ubmEgbGV0IHlvdSBkb3duLi4uIOKZqwo=");'

      I think you get that (and some more stuff) by having use 5.12; at the top of your script?

      I think that the reluctance to having it opt-out is that it would break backwards compatibility in a big way.

        If someone can't be bothered to use strict; use warnings; what makes you think they'll be bothered to use 5.12; instead? cavac's point was the on-by-default aspect and I agree that a major version bump is precisely the time to revisit such a beneficial but backwards-incompatible change.

        It's hardly such a great task to mitigate either. If someone really wanted to run code without the safety net then all they need to do is add no strict; no warnings; and they're done.

Re: If Perl 5 were to become Perl 7, what (backward-compatible) features would you want to see?
by Lotus1 (Vicar) on Oct 21, 2019 at 19:21 UTC

    haukex wrote:

    I imagine that, similar to Perl 6, a Perl 7 binary might be called perl7, with files being called .p7 or .pl7, .pm7, etc. Using this interpreter or this file extension would be the same as a use v7; (and turn on the corresponding feature bundle, etc.).

    Changing the file extension because of Perl 6 Raku doesn't make sense to me. We currently can run multiple versions of Perl 5 Perl ( :) ) on a single machine with existing methods so why not continue with this approach?

    The Python community navigated the 2.x to 3.x transition without changing the extension. They ended up changing the extensions after version 3.5 for reasons I don't know or care about, but they didn't put the version name into the extension. There are a lot of simple Python 2.7 programs that will run in 3.3. If the argument is that the 5 has become part of the language name then let's change it back to just Perl.

    Another example is the C language. There are dialects such as Cyclone that have different extensions but the .c extension is still used for the C language.

      From my admittedly limited experience with Python, the 2–3 change was a bit of a nightmare—and a major surprise coming from a community that is so culturally smug about their language—and any crutches or buoys might have been a help.

        "with Python, the 2–3 change was a bit of a nightmare"

        As someone who personally worked in an organization that dealt with Python, including while trying to deal with 2-3 change, it is/was more than a nightmare.

        I was in a job interview just this week where my interviewer stated "you dealt with Python 2-3 phase? That's crazy, we're still dealing with it now". That was beyond the silly parens after a print statement.

        Everything is so fast to change nowadays, nothing seems relevant. Perl 19, Python 86, C 4016, quarterly profits, not seeing long term, do what's coming out of 'college'... things seem to be speeding up to achieve the inevitability of futile.

        Interesting watching it happen, it has been.

        How has the Python 2 to 3 transition been compared to the Perl to Raku experience? More of a nightmare for me since I've never had to deal with Raku.

        With Raku using a different file extension it makes it easier to run both Perl and Raku on the same machine. But if updating Perl to version 7 means that we need to change Perl script file extensions and all the automated installs, environment variables, scheduled tasks, etc. that seems like a hassle. I don't see what the advantage is. The '.pl' extension is very well known. What if there is another application that uses '.p9' already? What happens when we get to '.p99'? Ok, that last question is a little tongue in cheek (meaning, not serious, with a wink and a grin). I don't think I'll be around to see Perl version 99 but you never know. It's just my two cents worth and I am not attacking Perl.

        How poorly the Python upgrade has gone is irrelevant since they didn't change the file extension. If they had I suspect the upgrade would have been worse in the long run. Easier in the short term maybe. Giving up '.pl' seems like giving up the brand. In the *nix world I suppose it is irrelevant since they don't need to bother with extensions. Just set it as executable and put in the shebang and go.

        Edit: typos.

A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://11107415]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (5)
As of 2024-03-29 15:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found