Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.99k stars 557 forks source link

Making format variables an opt-out feature; gaining much syntax #18393

Open leonerd opened 3 years ago

leonerd commented 3 years ago

What is the current overall state/feeling about formats in core perl?

I ask because there are so many (IMHO stupid annoying) punctuation vars related purely to formats. I could imagine a named feature, default on, that some newer version of perl might eventually turn off.

E.g. what if we could

use v5.34;

and get a whole bunch of syntax back?

Right now, e.g. I note that $= is the "current page length of the currently selected output channel, default 60 lines". How useless in the modern age. Someone suggested a spelling for the "numerical in" operator, e.g which would be spelled like

 4 @= 1..10  # true
12 @= 1..10  # false

Now, I'm not mailing to debate the merits of that particular syntax, but I note that right now we can't have @= as an operator because $= exists as a superglobal and thus @= is just the normal array part of it. All because of formats.

Likewise, $: is the "current set of characters after which a string may be broken to fill continuation lines in a format". Again I vote pointless. I had wanted slot variables of some core-supported object/class syntax to be spelled like

class Person {
    has $:name;
    method greet { say "My name is $:name"; }
}

But $: gets in its way. I am reasonably confident that nobody has ever wanted to set the continuation line characters for the currently selected format while writing a modern class module.

I feel that a "modern" Perl could do without these legacy format-related variables, if it gains us the ability to even consider lots of new useful syntax ideas that we'd much rather have instead. The above are just two examples I thought up in 5 minutes, I'm sure over the past decades we'll have had many more.

I propose that we could just gate the entire concept of formats behind a named feature like 'format'. Like the 'indirect' feature it would default on of course, but it is there for people to opt out of.

no feature 'format';

More specifically, the list of variables that would affect are:

$^A  $^L  $%  $-  $:  $=  $^  $~

(cross-posted to perl5-porters@ https://www.nntp.perl.org/group/perl.perl5.porters/2020/12/msg258658.html)

leonerd commented 3 years ago

I should perhaps clarify: all I'm suggesting that the feature would en/disable is the parser recognising those short forms of variable name. Nothing more.

Simply because we want some more dollar-char syntax back, for other things. Nothing would disable the idea of formats, nor the longer, more explicit method forms of interacting with them. E.g. the $: variable is still accessible via the longer method name

IO::Handle->format_line_break_characters("foo")

Hell for that matter, you can always:

{ no strict 'refs'; my $colon = ':'; $$colon = "new value" }

Turning off $: in the -parser- doesn't stop the ":" symbolic reference from working at runtime in a non-strict refs context, because that won't collide with anyone just trying to $:slot to do object access.

Perhaps we should name the feature

no feature 'format_vars';
skington commented 3 years ago

I'd always thought that formats were an obvious candidate for "make this a feature". (I appreciate that you're not talking about this, merely talking about the short versions of the variables.)

Also, if I saw anyone in my team using formats and using the format-specific magic variables, I'd strongly recommend that they said use English qw(-no_match_vars)and used the long variable names like $FORMAT_LINES_PER_PAGE or $FORMAT_LINE_BREAK_CHARACTERS, because to a first approximation, nobody knows what the short variable names mean. So I wouldn't expect any modern code to use those variables anyway.

Tux commented 3 years ago

I strongly disagree with @skington . The use English versions of variables is not clearer to many that do no share a native English tongue. if a script uses formats, the variables are known to the programmer. Trust me. I still maintain a lot of scripts that use it. I think I know them all if I need them, and I never even had any doubt in using them. Ever.

That being said, I see a lot of value in the original proposal of @leonerd - It is an opt-in to new syntax (or an opt-out to things not many of us use) and clearly shows value to many.

xiaoyafeng commented 3 years ago

IIRC, many people suggest clean perl's namespace and global variable. The first thing is to break all functions and variables into several class, like Format, String etc. then default to load some for compatibility, and no use.... for unloading. But since it looks like a big dirty job, every time it begans on disscussion and end silently.

haarg commented 3 years ago

I've never been a fan of use English;. Most people using super-global variables already know what the punctuation variables are for the few that are relevant to their work. The $SOME_THING names aren't meaningfully distinct from any other variable, so it isn't obvious that they carry magic behavior, unlike the punctuation variables.

It might make sense to create ${^SOME_THING} aliases for the current punctuation variables, based on their English names. This could reduce the reliance on punctuation variables, opening up parts of the syntax. And they are obviously super-global variables in a way that $SOME_THING are not. So even if you aren't yet familiar with the name, it would be an obvious signal for where to read about them.