Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

Even aside from that, some of us don't like really long lines of code. Having to scroll horizontally in GUI editors sucks, and I do most of my coding in good-old 80-column terminal windows. So it's not uncommon for me to split up a long statement into multiple shorter lines, since whitespace has no syntactic significance.

If CRLF becomes a potential statement terminator, then breaking a single statement across multiple lines not only becomes a minefield of "will this be treated as one or multiple statements?", but the answer to that question may change depending on where in the statement the line breaks are inserted!

If implemented, this change would make a mockery of any claims that Perl 7 will just be "Perl 5 with different defaults", as well as any expectations that it could be used to run "clean" (by some definition) Perl 5 code without modification.

Comment on Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff

Replies are listed 'Best First'.
Re^3: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by likbez (Sexton) on Sep 10, 2020 at 21:02 UTC
If implemented, this change would make a mockery of any claims that Perl 7 will just be "Perl 5 with different defaults", as well as any expectations that it could be used to run "clean" (by some definition) Perl 5 code without modification. Looks like a valid objection. I agree. With certain formatting style it is possible. But do you understand the strict as the default will break a lot of old scripts too. Per your critique, it probably should not be made as the default and implemented as pragma similar to warnings and strict. Let's call this pragma "softsemicolon" What most people here do not understand is it can be implemented completely on lexical scanner level, not affecting syntax analyser.	[reply]
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by dsheroh (Monsignor) on Sep 11, 2020 at 07:55 UTC
But do you understand the strict as the default will break a lot of old scripts too. Yes, that falls under my earlier statement about "expectations that it could be used to run "clean" (by some definition) Perl 5 code without modification." "Clean" Perl 5 code (by almost all definitions) already uses strict, so enabling strict by default will not break it. Backslash-escaped line endings are not currently recommended to be included in "clean" Perl 5 code. Indeed, they are not currently a part of the language at all. Thus, requiring them (even if only for some subset of mid-statement linebreaks) is something that will break existing "clean" code. What most people here do not understand is it can be implemented completely on lexical scanner level, not affecting syntax analyser. And what, exactly, does that have to do with anything? The change will be backwards-incompatible and break existing code. Whether it's broken by the lexical scanner or broken by the syntax analyzer is completely irrelevant. The code won't run either way.	[reply]
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by tobyink (Canon) on Sep 11, 2020 at 07:00 UTC
As I understand it, the current thinking is that the strict-by-default feature will just be the same strict-by-default feature that has existed since Perl 5.12. So a `use v7;` will turn on strictures, but if a script doesn't have a version declaration, it won't default to strict. If implemented this way, it has no chance of breaking old scripts. toby döt ink	[reply] [d/l]
Re^4: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by haj (Vicar) on Sep 12, 2020 at 10:26 UTC
What most people here do not understand is it can be implemented completely on lexical scanner level, not affecting syntax analyser. While I do not trust that assessment, it is also completely irrelevant. The question is not whether it can be implemented, but whether it should be implemented. You have received sufficient feedback that other monks agree that it should not.	[reply]
A reply falls below the community's threshold of quality. You may see it by logging in.


go ahead... be a heretic
	PerlMonks