I kept out of this but I don’t feel a broad enough picture is emerging so…

Perl 1 test suite due to mandating strict and dropping bareword filehandles. Does that matter? I guess not, but it feels like a loss to me.

That is an indefensible conclusion in my view and a good index point for why the Perl 7 move seems right: the objections are ultimately unmoving. I’ve been doing Perl for 22 years now and I’ve never once had to, directly, deal with Perl 4 let alone Perl 1. WRT strict and such… I only care about the command line. I expect it will remain or have a flag to remain, strict free.

Perl isn’t dead because there is too much of it out there and it has a large core of devotees but it has been on its sickbed since soon after I started using it and the Renaissance c 2005 is running on fumes.

Perl 6 was radical and a huge departure and exactly the right thing to do at the time. It was too ambitious though; and more importantly, it was opened up to too wide a design committee which is, thankfully, not happening with Perl 7. Perl 7 isn’t anywhere as radical but it also isn’t too ambitious. This feels like the sweet spot to me. Though it’s probably 10+ years too late; and even with a dedicated core willing and able to move Perl forward, riders are dragging their feet because it might mean…? They have to stick with 5 and won’t get new Unicode stuff? It won’t be a default install on *nix…? It’s already halfway to that as it stands.

Maybe it will all blow up. In an industry where winners and losers are chosen in a year or two, something has to change for Perl to cease shrinking; to gain significant new users, to get past its unearned lousy reputation, and to make devs interested in writing tools and apps against modern technology and needs. I’m not the one to change it but I am going to stay out of the way of the change and I encourage everyone to consider their own best utility in the equation. Something has to change.

If bareword filehandles no longer exist in Perl 7, how do you refer to STDOUT, or more commonly, STDERR, as in print STDERR "oops: ..."? Or, for that matter, STDIN, as in <STDIN>?

Is autoquoting here the token to the left of fat comma or is this the long-deprecated general bareword misfeature that use strict; has long disallowed?

And what is the supposed justification for removing heredocs?

Why is this starting to look like Perl6 all over again, just with a less-ambitious goal? Perl6/Raku at least had the excuse of targeting ahead-of-time compilation to machine code. What is the supposed benefit to Perl7?

Sawyer gave two practically unrelated talks and you both are mixing them up.

One about Perl 7 and one about what he wants to call "Standard Perl" a subset with BNF language definition, hence statically parsable by tools like Guacamole.

He was clear about that "Standard Perl" is not related to "Perl 7"

> If bareword filehandles no longer exist in Perl 7, how do you refer to STDOUT, or more commonly, STDERR, as in print STDERR "oops: ..."? Or, for that matter, STDIN, as in <STDIN>?

They are excepted, kind of built-ins.

I recommend watching those talks on YouTube before speculating and spreading rumors.

And the user you are responding to is pretty unknown here and had only 2 posts so far, so I'd be really careful to rely on such sources.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

The 1999 'postmodern' talk says: "Perl is humble. It doesn’t try to tell the programmer how to program. It lets the programmer decide what rules today, and what sucks. It doesn’t have any theoretical axes to grind." That's the Perl I want... not the Perl that says "your code will adhere to strict and warnings no matter what."

I have not mixed up the "Guac" talk with the Perl7 talk, but I fear it has provided insight into what Sawyer thinks is good and not-so-good about Perl syntax, and I don't like what I heard. Especially on the eve of leading a set of breaking changes to the language, I don't like to hear the leader saying how much he never liked a lot of perl-unique quirks and then naming a severe subset "Standard Perl." Further, I prefer a leader with enough awareness to understand how confusing it will be to call something he produces "Standard Perl."

Bareword filehandles are on the chopping block in the Perl 7 Announcement, and there it says except MAYBE the standard filehandles. I don't see how you can definitively tell people they are excepted like built-ins, unless you have more information. Strict and warnings are also discussed in the Perl 7 announcement. I did not mix anything up there.

It is true I do not spend a lot of time participating on forums--my other post here was in 2016--, if that disqualifies my thoughts here so be it.

He was clear about that "Standard Perl" is not related to "Perl 7"

I think everyone in this discussion is aware that this is officially the case, but the fact is that they are unavoidably connected in that Perl 7 and Standard Perl are both being driven by the same person. Don't forget that, in the Guac talk, Sawyer's clarification on this point was prompted by the moderator cutting in to tell him that the chat was filling up with people saying "OMG! The pumpking wants to gut Perl!!!"

So, yes, it is clear and correct that Standard Perl is not the plan for what Perl 7 (or 8, or any future official release) is meant to look like... but they are both the products of the same mind. To the extent that Standard Perl accurately represents Sawyer's concept of what the Platonic Ideal of Perl might look like, it also shows where he would like to see the language one day go, even if he knows that others would not agree with or accept those changes. (And note that I'm not saying it's a 100% accurate representation of Sawyer's "Ideal Perl", but there is almost certainly some high degree of similarity between the two.)

It's like a politician or a corporate leader expressing a personal opinion on a controversial topic. It's not the official position of their party or employer, but, despite that, it still reflects on the party/employer and (IMO, rightly) creates an impression that the party/employer at least accepts those views and may wish to unofficially further them, even if it doesn't openly endorse them.

They are excepted, kind of built-ins.

That is really a huge wart, far worse than general bareword filehandles could ever be. You still have the syntax cases, except now they are special cases instead of instances of a general rule.

And the user you are responding to is pretty unknown here and had only 2 posts so far, so I'd be really careful to rely on such sources.

Duly noted, which is one of the reasons I am in no particular rush: if Perl7 does turn into Perl6 all over again, I am confident that it will end similarly, with Perl5 carrying on.

I'd like to thank everyone for the fun discussion. It has clarified my thoughts on what a more exciting alternate-timeline perl7 would be. For what it's worth, here are my thoughts. Please don't take them seriously--I'm just some guy having fun imagining things.

Modernizations worth breaking existing perl code. The proposed changes don't thrill me enough to make me want to break existing code. Examples of what I would break code for:

• A repl.. When you run perl without a file argument, instead of reading STDIN it gives you a repl, and not an iPython knockoff, but a perly repl where you can alter the command grammar from the inside and available for programs to provide repls over ports like Lisps do.
• Retiring XS. Bring a first class API into the interpreter that insulates extensions from changes that need to be made in the interpreter. There would obviously have to be a prolonged grace period
• Objects. The semi-announcement that they'll put Cor in the Core is a good thing (as long as Cor actually delivers on its promises). But--if we can pull it into the language, that opens up interesting possibilities. Like, what avenues open up if an object is its own type of thing with its own sigil? And what could be done by adding object-context next to scalar/list/void contexts? Perhaps object-context plays a role in opening the door to auto-boxing the other types, as was mentioned in this thread elsewhere. I don't even know if it makes sense, but if we're going to break existing code, I'd really prefer to make perl-to-the-power-of-perl (huzzah), rather than keep naughty programmers from using bareword filehandles (meh).
• Perl on the Web via a webassembly cross-compilation target.

Then, we could have a perl7 announcement that says "we're breaking stuff but look what you get for it!", instead of "we're breaking stuff to take things away from you."

Things NOT worth breaking existing code. When your language is 30+ years old, if it's not big-ticket items like above, my stance is you should basically never break existing code. Follow the c++ model, and make extensions ugly but compatible. Old versions don't have to run new code, but new versions HAVE to run old code. That means prototypes don't move to attributes... perhaps signatures are relegated to attributes. Maybe say and state need different names or special names that can't conflict with anything else unless you add the aliases via 'use v7'. You'd get used to it. If you do it this way, you don't need feature guards on things once they get past the experimental stage, and you don't find yourself in 2020 where no one uses your features.

Objects. The semi-announcement that they'll put Cor in the Core is a good thing (as long as Cor actually delivers on its promises)

Actually, getting Cor into the core now that backward compatibility is going to be broken, IMO, doesn't make too much sense.

Moose creator, Stevan Little, pursued for a long time the idea of adding a powerful, modern and feature rich native OO framework to Perl, IIRC, he went into creating several prototypes, but time after time he hit the backward compatibility issue an at the end he throw in the towel (BTW, I recommend revisiting its Perl is not Dead, it is a Dead End talk as it is quite relevant to this discussion).

Ovid, who is a very clever but also practical guy, instead of persuading the perfect, but unrealisable OO system took a different view: could we get something that is useful, simple, cover most use cases and could be implemented without pervasive internal changes or breaking backward compatibility? And he come to Cor, which IMO is very good given the constraints, but definitively not state of the art.

So, in summary, we are getting the no-so-good solution now that the rule that had been making the really-good-ones infeasible is going to be lifted!

And he come to Cor, which IMO is very good given the constraints, but definitively not state of the art.

Hi salva. Thanks for your kind words. Version 1 of Cor is definitely trying to hit the “Minimum” in “Minimum Viable Product” because we don’t want to find ourselves building on a Jenga tower. That being said, when you say “not state of the art”, I would love to hear your thoughts on that. In particular, can you share solid examples of what you think state of the art should be?

Cheers,
Ovid

Hire me for training or software development.

Re: the dead end talk, thanks for that, I'll definitely check it out. I'm entirely ignorant of those prototype efforts, but am curious now how they compare to Cor.

The proposed changes don't thrill me enough to make me want to break existing code.

I'm mostly serious when I ask "what breaks".

If your code works with 5.32, why won't it work with 7?

If your code works with 5.32, why won't it work with 7?

If you aren’t inclined to change your code, plenty will break if the p7 announcement post is accurate—because flipping strict and turning off bareword file handles and indirect object calls breaks a lot of code.

If you are willing to change some pragmas, then nothing will break in 7. But what seems to bother me and almost no-one else is: they explicitly say you will lose compatibility promises when they move to 8–even guessed out loud that indirect object notation could be removed in 8 as an example. And they clearly don’t plan to wait too long to make that jump. What actually transpires may be very different, but I’m taking what was presented at face value, and I personally think it’s unwise. I could be convinced in the face of large gains (I listed a few that I would consider worth some breakage), but breaking compatibility because you think signatures look better where prototypes are? No thanks.

Modernizations worth breaking existing perl code

In my list there are two kind of reasons why backward compatibility could be broken:

1. Sane behavior and completing already implemented features: for instance, all the bugs related to Unicode; Windows support; prototypes that really allow me to mimic any builtin; etc. There are lots of edge cases that perl does not handle correctly.
2. Extensions that let me solve problems in different ways, or in other words, support for other programming paradigms: massive multi-threading; async programming, co-routines; type declarations; a modern, full-fledged object system; multi-methods; a proper exception system, that is used from the core; support for new platforms as the JVM, Android, the browser; binary compilation; etc.

In general, I don't think backward compatibility should be broken for features that are merely syntax sugar, specially when they can be activated on demand using a use feature foo or use v13 pragmas.

> Retiring XS. Bring a first class API

isn't FFI::Platypus supposed to solve this?

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

XS has two typical uses: one is writing interfaces to external libraries, that's also what FFI::Platypus does.

But then, XS is also a way to extend Perl in its own. It is another way to write modules, for instance, when performance matters or when access to the runtime internals is required to do something. I don't thing Platypus supports that.

I have zero experience using Platypus, but I doubt any library exposing a clean FFI would allow me to do the tricks I have done in XS sometimes... though, I would never say that disallowing those would be an unacceptable trade off!

• A Perl REPL would be very nice, agreed, but I do not think that that would break much code, especially if input-dependent: present REPL if STDIN is a terminal, read program if STDIN is a pipe or file.
• I do not know if retiring XS is as good an idea as it sounds — XS contributes significantly to perl's performance with some extensions.
• I am not sure that there are any usable sigil characters left in ASCII, although caret might be usable if it can be disambiguated from bitwise-XOR. Ampersand is both code sigil and bitwise-AND, so this might be workable.
• Generating webassembly sounds like a role for a B:: module.

A Perl REPL would be very nice, agreed, but I do not think that that would break much code,

It is possible you're right, and that's preferable. But: if I were presented with a first-class repl with completion and introspection, and also acts as an LSP server for $EDITOR, but to get it I had to accept a couple syntax compromises enabled via 'use v7', I'd accept that.

I believe it was one of your initial replies that clarified that for me... the question of the justification/value-proposition. I believe the justification given is: this will help us appeal to new users. I'm not sure that the proposed syntax adjustments will accomplish that. After all, Raku polished several of Perl's rough edges. Where are its new users?

The conversation I'm really not looking forward to is:

Me: "Oh, and we're going to have to make a few changes to the Perl scripts, and re-test them sometime this year." Boss: "If we have to do that, let's just get $new_hire to re-write them in $flavor_of_the_month."

a first class API into the interpreter ... insulates ... 

I find this important. Also, modernising the guts (without breaking anything, is that possible?) is equally important and will pay off in the future.

without breaking anything, is that possible?

No.

It is impossible to change the internals in any important way and keep XS code working.

Several years ago, Nicholas Clark (a perl's internals guru) tried porting perl 5 to parrot (the Perl 6 runtime), and IIRC, he didn't get too far because of XS. See Ponie has been put out to pasture.

So call it standard perl rebranded or backdooring Moose into Perl named for a mogrel dog this time, but the more I dig into this the more exclusionary and occluded the process becomes. And don't get me started about some who I've heard of being shadowbanned on p5p - receiving emails yet their emails getting delivered directly to /dev/null.

Can you be specific, what exactly is "concerning" to you about this proposal? What may leave people "shocked" about that wiki entry you quote?

"And don't get me started about some who I've heard of being shadowbanned on p5p - receiving emails yet their emails getting delivered directly to /dev/null."

How does this relate to the topic being discussed?

I am goncerned about the nature of implementation prototypes and that it was buried so deeply in the read that the guy who is responsible for Moose (end their elk) is greating the implementation, sure to turn into MooseNG. I don't expect any one to recall what I've said about it, so I'll state my tiny opinion again about what a unified OOP syntax/system looks like in Perl: if the resulting approach doesn't look and feel perlish then it's not going to be used or well adopted. I don't know what that looks like, the closest I've seen to date is Util::H2O. This may not be the way to go, but it is in the right direction.

To expand on the perlish nature of that I mean:

• if it results in gobs of pre-declarations like Moose, it will fail (again). Why? I don't think I need to answer that one.
• if it looks identical to insert your realy OOP language here, it will fail. Why? Because people who use it will go to another language when they realize support is superficial compared to other languages at best. It's also the opposite of optimize for fun. It's more like optimize so it doesn't look like Perl
• if it necessarily restricts the user to a subset of "standard" Perl, it will fail. Why? Because it violates the principle that Perl is defined by perl, and so far (and likely forever), will resist a traditional standard BNF; Perl may even have more to do with its Recursively enumerable characterisitcs than anything. This is why perl is necessarily part of Perl's standard definition. More proof of this is Perl 6's ash heap of attempts to do what perl does: at least 2 VMs, at least 3 intermediate/bootstrap languages, forray into fundamental support of grammers. There are more, but I'd have to think about it a little more.

So my challenge is to those who actually deal with implementation is to create something that extends Perl using the full breadth and POWER^POWERPOWER that perl as a *framework* offers. And recongizing perl as a Recursive enumeration framework and not the thing to be extended, it is Perl that needs to be minimally extended and decorated. IOW, it's not about creating a grammar using Marpa or go down the same failed path a Perl 6 - a failure so HUGE that it resulted in a completely new language that completely and utterly missed the target, yet simultaneously produced as VERY interesting thing so influenced by the need to define perl that itself had to become a formal Recursive enumeration framework. But perl is not a formal one of those, that's just one of its qualities. A tricky beast, indeed. I don't know perl internals, but I know that it is a beautiful and powerful mess that can most certainly handle whatever is needed to scratch this OOP itch with no or a few very boring modification.

Of course, all of the above could be complete garbage. There is a lot I admittedly don't know. My hope is merely to get people to think critically so that we can get a win. Everyone deserves it, especially the people who maintain this glorious mess for us.

Meh. Ovid's preachin' 'cause he's reachin'. I would be *very* surprised if he is not overstating the buy-in he has from ... anybody.

I do agree that it would be good for P5P and Sawyer to provide updates on their thinking and plans for the unwashed masses. That way there'd be less guesswork and innuendo.

(And FWIW I am opposed to bloating the Perl core with *any* OOP framework, even if there existed one as good as Ovid's dream. One size does not fit all in Perl programming.)



The way forward always starts with a minimal test.