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

Highly desirable Make a semicolon optional at the end of the line
Highly undesirable. If things to be made optional for increased readability, not this, but making braces optional for singles statement blocks. But that won't happen either.
Highly Questionable Introduce pragma that specify max allowed length of single and double quoted string
Probably already possible with a CPAN module, but who would use it? This is more something for a linter or perltidy.
Highly desirable Compensate for some deficiencies of using curvy brackets as the block delimiters
Unlikely to happen and very unundesirable. The first option is easy } # LABEL (why introduce new syntax when comments will suffice). The second is just plain illogical and uncommon in most other languages. It will confuse the hell out of every programmer.
Make function slightly more flexible
a) no b) Await the new signatures c) Macro's are unlikely to happen. See the problems they faced in Raku. Would be fun though
Long function names
Feel free to introduce a CPAN module that does all you propose. A new function for trimming has recently been introduced and spun off a lot of debate. I think none of your proposed changes in this point is likely to gain momentum.
Allow to specify and use "hyperstrings"
I have no idea what is to be gained. Eager to learn though. Can you give better examples?
Put more attention of managing namespaces
I think a) is part of the proposed OO reworks for perl7 based on Cor, b) is just plain silly, c) could be useful, but not based on letters but on sigils or interpunction, like in Raku</lI.
Analyze structure of text processing functions in competing scripting languages
Sounds like a great idea for a CPAN module, so all that require this functionality can use it
Improve control statements
Oooooh, enter the snake pit! There be dragons here, lots of nasty dragons. We have has given/when and several switch implementations and suggestions, and so far there has been no single solution to this. We all want it, but we all have different expectations for its feature sets and behavior. Wise people are still working on it so expect *something* at some time.

Enjoy, Have FUN! H.Merijn

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

Replies are listed 'Best First'.
Re^2: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff by Jenda (Abbot) on Oct 17, 2020 at 19:12 UTC
Re 3)a) - closing all inner is absolute nonsense, but it would make sense to use that as a further safeguard to prevent the case you mismatch braces in one place and accidentally "fix" it in another. I think it would be nice to be able to say "this is supposed to be the closing brace of matching that particular opening one, scream at me if it ain't". I don't think the "reversed label" syntax is possible without breaking a lot of stuff and the label syntax to mark the opening brace doesn't work well if you are not crazy enough to reserve a whole like just to the opening brace, but something like `if (whatever) { ... blah blah blah if (something) { ###FOOBAR ... a complicated code with plenty of braces } ###/FOOBAR } else { ... some more code }` [download] could actually be helpful in complex code in case you accidentally type one too many/few closing braces within that marked block. You'd still have to have the right number and nesting of braces, but you'd have one more check in place should you decide to ask for it. Jenda 1984 was supposed to be a warning, not a manual!	[reply] [d/l]
A reply falls below the community's threshold of quality. You may see it by logging in.
A reply falls below the community's threshold of quality. You may see it by logging in.