What can/should we break?

[atoomic]

Identify features which block/slow down future developments by adding complexity to the parser...

In other words: what legacy/monstrosity we want to go away

[leonerd]

I've often pondered a thought-experiment in which we add a sortof "anti-features" set, controlled by some internal bitflags or whatever and accessed by a legacy pragma:

no legacy 'vars';

and now suddenly all the annoying punctuation variables go away. Or

no legacy 'indirect';

and we throw out the misfeature that was indirect method syntax. It would be an easy one to experiment with suggesting features people don't want, adding bitflags for them, and then testing out in practice in your own code what you can easily get away with turning off.

If they remain maybe we even start suggesting that a given use feature :VERSION might start to imply turning off some legacy features automatically.

[leonerd]

Personally a few (controversial I know) features come to mind:

• no map EXPR, ... or grep EXPR, ... because those are a stupid specialcase in the parser and break humans' heads on code such as map { name => $value }, LIST ...

[leonerd]

• a lot of the sillier punctuation vars - e.g. $( and $) for POSIX group IDs. Really? I would love to gain the ability to use $(barename here) syntax for some ideas, but $( for what really ought to be spelled POSIX::getgid() (or is it getegid() - I forget) gets in the way.

[leonerd]

• Barename handles. All of them. Yes even STDERR. Now that $* is truely dead we could perform a mass migration to spelling them all like perl6raku, in $*STDERR, etc.. By moving all of the process-wide ones here - even e.g. %*SIG and %*ENV we could have a much cleaner and tidier splitting of specialcased variable names. They're all the ones with the star.

PS this would now mean those handles all behave like regular perl scalars, so I can pass one into a regular function by just doing func($*STDERR) spelling it the same as I would to print or anything else, so I don't have to explain to perl newbies why I can print STDERR ... but must func(\*STDERR)

[leonerd]

• Default stringification of references. I call this the "Hello HASH(0x12345678)" problem. I tried getting rid of it in https://metacpan.org/release/PEVANS/stringification-0.01_004 but the problem is really hard to solve in an XS module because core perl does it too easily. On those super-rare occasions I really want to use an object ref as a string (e.g. for hash key purposes) I usually know I want to do this so I can go via a special function - maybe use Scalar::Util::refaddr or similar. But see also #3

[Leont]

I don't think there's much we can break in a way that would benefit the perl community.

We really shouldn't break things just because we dislike them. This is what perlcritic is for. IMO we should only break things when there is a clear and significant practical advantage to it, and little disadvantage (e.g. 5.14 adding a requirement of putting whitespace between s/// and and made the /a modifier possible).

I've often pondered a thought-experiment in which we add a sortof "anti-features" set, controlled by some internal bitflags or whatever and accessed by a legacy pragma:

Is it worth adding the complication? In many cases probably not (though I will surely welcome no legacy 'indirect')

[atoomic]

I would like to kill the legacy package separator a''b''c instead of a::b::c maintaining that logic for parsing every stash name seems absurd to me.

My idea is we should break stuff that blocks us from having a better language, easier to maintain and faster run time...

[Abigail]

On Mon, Oct 14, 2019 at 05:51:10PM -0700, Leon Timmermans wrote:

I don't think there's much we can break in a way that would benefit the perl community.

We really shouldn't break things just because we dislike them. This is what perlcritic is for. We should only break things when there is a clear and significant practical advantage to it, and little disadvantage (e.g. 5.14 adding a requirement of putting whitespace between s/// and and made the /a modifier possible). >

I complete agree with that.

Abigail

[arc]

Personally a few (controversial I know) features come to mind:

• no map EXPR, ... or grep EXPR, ... because those are a stupid specialcase in the parser and break humans' heads on code such as map { name => $value }, LIST ...

This is very much a side issue to the general questions raised in this ticket, but: Paul, I'm afraid I strongly disagree with this specific proposal. I did a lightning talk about this at a London.pm tech meet a few months ago, and I'm happy to explain my position in person / when I have time, but the single-sentence version is that it's actually map BLOCK LIST that's the special case.

[ap]

What can/should we break?

That question is asking “how much existing Perl code can we throw away?”   In a language whose influx of new code in the world has slowed down rather dramatically in the last couple of years, that is asking “what can we do to reduce our relevancy?”   Back in the day I liked using a language with a good “the good parts” core which was quietly relevant without the hype. This new reality, I don’t enjoy so much.

Perl 6 was the designated incompatible (re)design of Perl. Every other independent attempt to shed baggage from Perl 5 over the years has foundered (Kurila and Moe come to mind right away but I know I forget more from the past). Why people think it’s a good idea to turn Perl 5 itself into a more historically encumbered, lesser version of the Perl 6 effort, without even the benefit of a good designer at the helm, is beyond me.

Which is to say, what @Leont said.