Let's remove most (if not all) perl5-oriented error messages for variables

[AlexDaniel]

See these tests: https://github.com/perl6/roast/blob/1f54bd963c2d75a7b7b28a17777def4682c28436/S32-exceptions/misc.t#L195-L207

Really, only a few of those are actually helpful (although I can no longer tell which ones because I don't write any perl5 code nowadays). The rest just gets in the way when you don't even think about perl 5.

Most importantly, I want to break “perl6 is the next version of perl5” connection as much as we can. Giving less error messages like this is going to help with that.

[zoffixznet]

👍 on removing them. I'm a Perl 5 programmer who came to Perl 6 and these Perl5-ism errors were never helpful to me and only got in my way when I wrote proper Perl 6 code.

[samcv]

What other context would people be using those variables? Do they actually get in the way, or is it more you make a typo and instead of getting a syntax error get one of these?

[zoffixznet]

Do they actually get in the way

Depends on the variable. Some of them could be properly used in Perl 6, but their use is entirely blocked by these error messages:

$ perl6 -e '{ $:f.say }(:42f)'
42
$ perl6 -e '{ $:F.say }(:42F)'
===SORRY!=== Error while compiling -e
Unsupported use of $: variable; in Perl 6 please use Form module
at -e:1
------> { $:F⏏.say }(:42F)


$ perl6 -e '{ $^v.say }(42)'
42
$ perl6 -e '{ $^V.say }(42)'
===SORRY!=== Error while compiling -e
Unsupported use of $^V variable; in Perl 6 please use $*PERL.version or $*PERL.compiler.version
at -e:1
------> { $^V⏏.say }(42)
$ perl6 -e '{ $^A.say }(42)'
===SORRY!=== Error while compiling -e
Unsupported use of $^A variable; in Perl 6 please use Form module
at -e:

My main argument against these is they assume too much. A novice Perl 6 programmer who never programmed Perl 5 might be utterly confused why they're being recommended "Form module" when they tried to write an implicit signature.

It's a given that the vast majority of Perl 6 code is written by people who know Perl 6 and not by novices who'd might benefit from these errors. Yet, it's that majority that has to suffer and work-around these errors.

It's not just the variables either. I never wrote C++ in my life, yet the compiler blocks me from using perfectly valid Perl 6 code:

$ perl6 -e 'my $stuff := new class { }:'
===SORRY!=== Error while compiling -e
Unsupported use of C++ constructor syntax; in Perl 6 please use method call syntax
at -e:1
------> my $stuff := new class ⏏{ }

I'm perfectly aware of how say routine works, yet I'm blocked from writing perfectly valid Perl 6 code and have to stick ugly parentheses where none are needed:

$ perl6 -e 'for ^10 { .say; ++$ %% 3 and say }'
===SORRY!=== Error while compiling -e
Unsupported use of bare "say"; in Perl 6 please use .say if you meant to call it as a method on $_, or use an explicit invocant or argument, or use &say to refer to the function as a noun
at -e:1
------> for ^10 { .say; ++$ %% 3 and say⏏ }

IMO any such thing that blocks valid Perl 6 code should be removed and placed into "NoviceHelpers::Perl5", slang module that enables all these errors. The beginners could load whatever module they need and the module can implement even more of such features and be more targeted to other languages as well.

And I'm not buying the argument that beginners wouldn't know to load such a module. They learned to put the useless use v6 in their code; they can learn to put use NoviceHelpers::Perl5

[lizmat]

I'm sorta in two minds about this, especially regarding: https://www.perl.com/article/an-open-letter-to-the-perl-community/ .

The thing is that many of these date from ~15 years ago: Perl 5 has evolved since then, so in some cases they refer to older false friends.

I mean, the bare say could even be useful for Perl 6 programmers. But others may be confusing. So maybe the errors should stay, but the references to other languages should be removed?

[zoffixznet]

So maybe the errors should stay, but the references to other languages should be removed?

To me, the issue isn't the references to other languages, but the errors interrupting my flow when I write perfectly valid Perl 6 code.

[smls]

This has been brought up on IRC in the past, and I think someone suggested making such errors/warnings opt-in via an environment variable or perl6 command-line flag, so that "Porting from Perl 5 to Perl 6" guides etc. could tell their particular audience to turn on that flag, while other people wouldn't have to be hindered or confused by such errors/warnings.

[niner]

The opt-in suggestion reminds me a bit of php.ini and all the issues global configuration of a language causes. An environment variable would e.g. be propagated to module compilation. So using code from a Perl 6 pro in a program written by a newbie coming from Perl 5 would become harder.

I have found all the P5ism error messages to be incredibly helpful when learning Perl 6. And I've told my fellow colleagues to just try the Perl 5 code and follow the error message when they don't know what a thing is called in Perl 6. So I'd hate to lose this help.

Maybe we could just weed out the rather obscure variables like everything that has got to do with formats?

[zoffixznet]

The opt-in suggestion reminds me a bit of php.ini and all the issues global configuration of a language causes. An environment variable

I imagined the opt-in would be implemented as simply an alternate exceptions handler. We already support them. And if any cases remain where that can't be handled by examining the Exceptions objects in the handler could be handled with a slang instead. Thus, the new users coming from other languages would be told to just load a module (e.g. use NoviceHelpers::Perl5) and this would also stimulate users to release other similar modules into ecosystem: use NoviceHelpers::Python, use NoviceHelpers::Ruby, etc.

I have found all the P5ism error messages to be incredibly helpful when learning Perl 6

That's contrary to my experience. (I did come to Perl 6 from Perl 5)

[stmuk]

I also found the Perl 5 error messages in general very useful.

It would be a mistake to remove significant ones based on sour grapes over a reddit thread.

The ones referenced would be useful in catching the occasional typo -- especially if someone is context switching between 5 and 6.

[zoffixznet]

It would be a mistake to remove significant ones based on sour grapes over a reddit thread.

What reddit thread? I see none mentioned in this issue, which existed for over 21 days.

The proposal is to move these errors into the ecosystem. This would eliminate the assumption that every newcomer is a Perl 5 programmer and only the programmers who'd actually benefit from these errors would be blocked from using valid Perl 6 features. This would also encourage users to implement other similar modules, for other languages.

[jnthn]

My feeling is:

• People have mixed opinions on whether these should stay or go
• I'm mostly sympathetic to the "this practically helped me" and "this got in my way" arguments
• There's a bunch of these messages. It's not clear that the set of things people found helpful, and the set of things that got in people's way, strongly overlap.

For example, $:F probably helps nearly nobody. Does it get in the way? I could imagine it might, if somebody decided to use uppercase names for their named parameters.

As to the new one: there's a lot of languages where new Type() is the right way to do constructor stuff. I know because I write in a lot of them. I probably have to be having a bad day to write that in Perl 6. But it happens, and I've appreciated the hint. At the same time, we could probably handle this one just as well by putting a hint into the error reporting for undeclared routines, not forbidding it in the grammar. In some other cases, we may find there's a way to go that doesn't block things, but does let us get a handy hint in.

[ghost]

If they have to stay I'd at least like some way to express use v6; no v5; no php; no c89;. Please, more DWIM, less WATs like this one:

> /<[ 0..9 a..z A..Z - _ ]>/
===SORRY!=== Error while compiling:
Unsupported use of - as character range; in Perl 6 please use .. for range, for
explicit - in character class, escape it or place it as the first or last thing
------> /<[ 0..9 a..z A..Z -⏏ _ ]>/

…I really don't need things like this in the middle of a very long day of grammar debugging. There's no ambiguity there, the compiler can even see I've used the thing it's telling me to use.

But most of all I want to work in one language, not be constantly paranoid about the compiler automatically taking offence to imagined slights and getting in my face on some unrelated language's behalf. They do that more than enough manually already!

[zoffixznet]

Please, more DWIM, less WATs like this one:

Just got burnt on that myself:

./t/01-basic.t .. ===SORRY!=== Error while compiling [...]
------> my regex cycle   { <.ws>? <[−-⏏+]>? \d**{1..3} <.ws>? }

Wasted some time just because some other language I'm not even coding in uses this syntax for character ranges.

[AlexDaniel]

Related IRC discussion: https://irclog.perlgeek.de/perl6/2018-05-13#i_16159259

TL;DR some of these messages are very outdated (e.g. Unsupported use of $, variable; in Perl 6 please use $*OUT.output_field_separator()), so we should at least validate that suggestions are reasonable

[zoffixznet]

8ae82a558b addresses this in some form, apart from exposing some bugs with constructs that used to be blocked by the X::Obsolete throwage: https://irclog.perlgeek.de/perl6-dev/2018-05-17#i_16175545

[zoffixznet]

Another case where a perfectly valid program errored out on me because it thinks I'm writing in a language in which I never even used $]

<Zoffix__> m: say ({my $a := 3**++$; my $b :=  2**++$; [$a, $b, $b-$a, ($b-$a)**++$]} ... *).head: 10
<camelia> rakudo-moar c441d8d8b: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Unsupported use of $] variable; in Perl 6 please use $*PERL.version or $*PERL.compiler.version␤at <tmp>:1␤------> =  2**++$; [$a, $b, $b-$a, ($b-$a)**++$]⏏} ... *).head: 10␤»

[smls]

So it looks like the current course of action is to remove some (particularly outdated) Perl-5ism error messages altogether, while the rest continues to always block compilation when encountered?

Wouldn't it make more sense to:

• Ignore most of p5isms when the program compiles fine as Perl 6.
• But mention them in the error message when the compiler croaks on a syntax error in their vicinity.
• Maybe allow a few particularly helpful ones to remain fatal, but only when it looks like from context that it was really meant as a p5ism.

For example:

• $]: The chance that someone tries to use this as the Perl 5 variable, and at the same time manages to accidentally make the program compile as valid Perl 6 (without a mismatched-bracket error somewhere), is.probably quite low. A good candidate for turning non-fatal.

• In fact, all Perl 5 variables can probably become non-fatal. While there are syntactic differences between the two languages that can trip up polyglots, the fact that Perl 6 has done away with almost all the symbolic variables, is something that Perl 6 newbies coming from Perl 5 learn really fast. Maybe go over the list and check if there are any that are easy to accidentally use without violating the Perl 6 grammar... but if not all, then certainly most, can go non-fatal.

• /<[ a-z ]>/: This is not just a Perl 5 issue; this usage of the dash is part of the basic POSIX regexes standard, i.e. the common denominator of all the regex flavors outside of Perl 6, from Gnu grep to every modern-day programming language. And it's a commonly used feature, too, and I can confirm that it's easy to write it in Perl 6 by accident...
  But it would be a good candidate for a context-sensitive error:

  • /<[ a-d ]>/ or /<[ 2-9 ]>/ (i.e. lower letter to higher letter, or lower number to higher number, with neither already part of a P6 range) --> assume thinko, throw error.
  • /<[_-m..s]>/ or /<[.:-_]>/ (i.e. other cases) - ignore.

• new Type() - Helpful, but will be an "Undeclared routine" error anyway, unless the user has declared a routine called new, in which case they'll expect that to be called. --> Make the p5ism hint non-fatal.

And so on...

@stmuk

I also found the Perl 5 error messages in general very useful.

Helpful in explaining the source of a syntax error, or helpful in stopping the compilation of a Perl 6 program that would have otherwise compiled (but done the wrong thing due to the p5ism thinko)? Can you help collect some more examples of the latter?

[zoffixznet]

Here is a user getting tripped by the "help" from Perl 5 errors, confused why valid syntax is invalid in this case:

donpdonp | m: my $host = "abc"; "@{$host}"
-- | --
17:13 | camelia | rakudo-moar f9743ad82: OUTPUT: «=== SORRY!===   Error while compiling <tmp>␤Unsupported use of @{$host}; in Perl 6  please use @($host) for hard ref or @::($host) for symbolic ref␤at  <tmp>:1␤------> my $host = "abc"; "@{$host} ⏏ " ␤»
17:14 | donpdonp | is that a bug, or p6 syntax creativity that im not aware of?

[lizmat]

My take on this now is: use isms to not complain about all of these issues. And make this the default in 5.d or 5.e. This is now available:

use isms;
my $host = "abc";
dd "@{$host}";  # "\@abc"

[zoffixznet]

the default in 5.d or 5.e

cue Perl 5 folks rioting

[AlexDaniel]

Some related changes:

• Add use isms <C++> and make use isms assume all available "isms" (now 'Perl5' and 'C++')
  [57f8927] [c6c2b6c] [528def4]

[AlexDaniel]

Wouldn't it make more sense to invert the logic (given that we're making it the default anyway) and call it training-wheels? So use training-wheels <C++> if you're switching from C++.

[ZzZombo]

Yes, I like this more than the other. It's just a silly thing to pick on a valid syntax in this language just because some other also has it.