http://qs1969.pair.com?node_id=11121538

Note to zealots who consistently put negative ratings on my comments:
I do not care, but you prevent people who are not logged to the site from reading them and as such you censor my speech. Please remove them. This is a free forum not your clique watering place. The fact that you are unable to appreciate or understand them does not mean that they have no value to other people. Not all users here are Perl zealots. As Prince Talleyrand recommended to young diplomats: first and foremost not too much zeal. This is fully applicable to Perl advocacy. On other words by behaving like a clique you are harming Perl acceptance and future.
What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff. I compiled some my suggestions and will appreciate the feedback:
  1. [Edited] [Highly desirable] Make a semicolon optional at the end of the line, if there is a balance of brackets on the line and the statement looks syntactically correct (optional pragma "soft semicolon", similar to the solution used in famous IBM PL/1 debugging compiler). That can help sysadmins who use bash and Perl in parallel and work from command line with vi or similar editors, and are not using such editors as Komodo Edit which flag syntax errors. If might make sense to enable this pragma only via option -d of the interpreter. In this case it will suit as a pure debugging aid, cutting the number of iterations of editing the source before actual run. It does not make much sense to leave statements without semicolons in the final, production version of the program. See, for example, the discussion in Stack Overflow Do you recommend using semicolons after every statement in JavaScript
  2. [Highly Questionable] Introduce pragma that specify max allowed length of single and double quoted string (but not any other type of literals). That might simplify catching missing quote (which is not a big problem with any decent Perl aware editor anyway)
  3. [Highly desirable] Compensate for some deficiencies of using curvy brackets as the block delimiters:
    1. Treat "}:LABEL" as the bracket closing "LABEL:{" and all intermediate blocks (This idea was also first implemented in PL/1). [Edited]This feature also makes complex nesting structures more reliable, and can't be compensated with the editor, as people often just forget to check and assume that a complex nesting structure is OK, while in reality it is not. Some people argue that complex nesting structures should not exist. Those should not use this feature at all, but we should not allow them to dictate how we should program our scripts, especially in areas they have no clue about. For example, hand-written lexical and syntax analyzers and similar scripts with recursion and a very complex decision making.
    2. [Edited]Treat "}.." symbol as closing all opened brackets up to the subroutine/BEGIN block level and }... including this level (closing up to the nesting level zero. ). Along with conserving vertical space, this allows search for missing closing bracket to be more efficient. It might be possible to treat them as macros, which interpreter expands in the source code to regular brackets. Like soft-semicolons this feature mainly benefits those who use command like and vi, not some sophisticated GUI editor and allows dramatically cut the area of search for missing bracket in long scripts. .
  4. Make function slightly more flexible:
    1. Introduce pragma that allows to define synonyms to built-in functions, for example ss for for substr and ix for index
    2. Allow default read access for global variables with subroutines, but write mode only with own declaration via special pragma, for example use sunglasses;
    3. Introduce inline functions which will be expanded like macros at compile time:
      sub subindex inline{ $_[0]=substr($_[0],index($_[0],$_[1],$_2])) }
  5. As extracting of sub-string is a frequent operation in text processing scripts (for example to limit the scope of index function, or regular expression) in many cases it is more convenient to have indexes of starting and ending symbols, not a starting symbol and length. Also extracting of a sub-string sometimes is performed by eliminating head and tail with particular sets of characters like in tr/.../.../d ; often those characters are white space, a frequent operation for which something less general then regex might be beneficial.
    1. Adopt "range" notation. Allow to extract a sub-string via : or '..' notations like $line [$from:$to] (label can't be put inside square brackets in any case)
    2. Generalize chop and chomp with rtrim (see below).
    3. [Edited] Implement similar to head and tail functions called ltrim and rtrim as well as trim which can work with the set of characters like tr, not only integers. or substrings :

      trim(string,tt/leftcharacter_set/, tt/right_character_set/);
      [Edited]

      which deleted all characters from the first character set at the left and all characters from the second character set from the right, If only one set is given it uses for trimming both at the left and right

      Similarly ltrim($line,7) is equivalent to substr($line,7) but can be called as subroutine, not only as function. Similarly ltrim($line,'&lth1;) is equivalent to substr($line,max(0,index($line,'<h1')). In case of usage of tr datasets it should operate similar to trim but only on one "side" of the string --left or right.

  6. Allow to specify and use "hyperstrings" -- strings with characters occupying any power of 2 bytes (2,4,8, ...). Unicode is just a special case of hyperstring
    1. $hyper_example1= h4/aaaa/bbbb/cccc/;
    2. $hyper_example2= h2[aa][bb][cc];
    3. $pos=index($hyper_example1,h4/bbbb/cccc/)
  7. Put more attention of managing namespaces.
    1. Allow default read access for global variables, but write mode only with own declaration via special pragma, for example use sunglasses.
    2. Allow to specify set of characters, for which variable acquires my attribute automatically, as well as the default minimum length of non my variables via pragma my (for example, variables with the length of less then three character should always be my)
    3. Allow to specify set of character starting from which variable is considered to be own, for example [A-Z] via pragma own.
  8. Analyze structure of text processing functions in competing scripting languages and implement several enhancements for existing functions. For example:
    1. [Trivial to implement]Allow TO argument in index function, specifying upper range of the search. That can help to exclude unnecessary use of substr to limit the range of search in long strings
    2. [Trivial to implement]Extend the function tr with two new options: E -- exclude, which stops translation at the first symbol which it not in set1 and returns the position of this symbol, and R which can be used with option E to scan string in the reverse direction like rindex. For example, $line=~tr/ \t\n//dER will remove whitespace from the end of the string, while $line=~tr/ \t//dE will remove leading whitespace. Also those new options can be used for searching the position of a symbol in the string more efficiently, for example $pos=$line=~tr/_a-zA-Z//cE will return the position of the first letter in the string.
    3. Implement "delete element" function for arrays.
  9. Improve control statements
    1. [Edited] Eliminate keyword 'given' and treat for(scalar) as a switch statement. Disable smart matching by default. Interpreter should flag as an error if no $_ used in when construct to allow optimization (in this case elsif should be used:
      for($var){ when($_ eq 'b'){ ...;} # means if ($var eq 'b') { ... ; last} when($_ &gt;'c'){...;} } # for
    2. [Questionable] Extend last to accept labels and implement "post loop switch" (See Donald Knuth Structured Programming with go to Statements programming with goto statements)
      my rc==0; for(...){ if (condition1) { $rc=1; last;} elsif(...){$rc=2; last} } if ($rc==0){...} elif($rc==1){...} elif($rc==3){...}

      [Edited]One possible implementation would be usage of Pascal-style local labels (limited to the block in which they are defined), each of which corresponds when in the loop body

      for ...{ when (...); when (...); }after{ default: 1: ... 2: ... }

Replies are listed 'Best First'.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Corion (Patriarch) on Sep 10, 2020 at 07:03 UTC
      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.

        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.

      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.
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Tux (Canon) on Sep 10, 2020 at 08:52 UTC
    1. 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.
    2. 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.
    3. 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.
    4. 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
    5. 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.
    6. Allow to specify and use "hyperstrings"
      I have no idea what is to be gained. Eager to learn though. Can you give better examples?
    7. 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.
    8. 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
    9. 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

      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 }

      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!

    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.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO stuff
by hippo (Bishop) on Sep 10, 2020 at 08:34 UTC
    9. ... a. Eliminate keyword 'given'

    That I can agree with. The rest of your proposals seem either unnecessary (because the facilities already exist in the language) or potentially problematic or almost without utility to me. Sorry. That's not to say you shouldn't suggest them all to p5p for further review of course - it's only the opinion of a humble monk after all.

    9. ... b. ... Extend last to accept labels

    I have good news: it already does


    🦛

      > I have good news: it already does

      What I mean is a numeric "local" (in Pascal style; can be redefined later in other blocks ) label in the context of the Knuth idea of "continuations" outside the loop

Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by tobyink (Canon) on Sep 12, 2020 at 23:13 UTC

    1: Auto-semicolons are bad. Look at Javascript. Who deliberately uses them? Nobody. Who occasionally needs to workaround them? Everybody.

    2: Runaway quotes are usually caught anyway; it's just the error message happens several lines further than you expect it to be. For a missing quote mark not to cause a syntax error requires a perfect storm of conditions. (Usually involving quote marks being used in comments.) To anybody using editors with syntax highlighting, this isn't usually much of an issue anyway. I don't think it's necessarily a bad idea, as long as heredocs are exempt. I just don't think it gives us much.

    3a: I see no use for this feature. What would it be used for?

    3b: It's already possible to close multiple levels of braces on one line. The syntax for it is: }}. You even have fine-grained control over how many levels you close. If you want to close four levels, use }}}}. If you're closing less than four levels, this existing syntax is as compact or more compact than what you suggest. If you're routinely closing more than four levels, consider restructuring your code so it doesn't have so many deeply nested blocks.

    4a: The frequently used built-ins mostly have pretty short names anyway. Any shorter and they lose descriptiveness. I don't see how this is a win.

    4b: I don't know exactly what you mean.

    4c: I really need to fix up my macros implementation and put it on CPAN.

    5a: I guess this is a decent one.

    5b: By translation table, you mean tr///? Seems like overkill.

    5c/5d: head, tail, trim, ltrim, and rtrim are so trivial to implement, I don't see the need for them to be in core. There's a bunch of implementations on CPAN already.

    6: for what purpose?

    7: global variables are design smell. "Let's introduce new features for global variables" is like saying "let's make the two-argument open more powerful".

    8a: It's not hard to check if the return value of index is below a certain limit.

    8b: Don't the existing substr and splice functions do this?

    9a: Umm, when is already allowed in for loops.

    9b: I don't understand what's made easier by this.

      Thank you for reviewing all the proposals. Instead of just "soft semicolon" :-)
      5a: I guess this is a decent one.
      Some progress :-).
      8a: It's not hard to check if the return value of index is below a certain limit.
      No. For example, in bioinformatics FASTA sequences the string can be several gigabytes. You need to use substr right now to limit the search area.
      9a: Umm, when is already allowed in for loops.
      There are a couple of unresolved problems. You need to suppress "when is experimental" warning to use it with

      no warnings 'experimental::smartmatch';

      and the form when('a') involves smart matching as as such might not work in future releases. So it is essential to disable smart matching in when in order to use it (in this case the syntax should be when( $_ eq 'a')... and the form when('a') should generate an error, which I do not think is currently possible.

        You need to suppress "when is experimental" warning to use it

        No, you don't. It will quite happily work without suppressing the warnings, you just get the warnings is all. And that's a good thing because it means that you don't forget that it's experimental.


        🦛

Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by haj (Vicar) on Sep 10, 2020 at 11:00 UTC

    That's quite some work you've invested here. I've looked at them from two perspectives:

    • How does it help when I'm writing code?
    • How does it help when I'm reading code (mostly written by someone else)?

    In summary, your suggestions don't perform that great. These are rather nerdy ideas where I don't see which problem they solve. There isn't much to be added to the comments of other monks, so I'll keep attention to two items:

    I challenge the claim that closing more than one block with one brace allows search for missing closing bracket to be more efficient. It just hides problems when you lost control over your block structure. Source code editors easily allow to jump from opening to closing brace, or to highlight matching braces, but they are extremely unlikely to support such constructs.

    I challenge the claim that extracting of substring is a very frequent operation. It is not in the Perl repositories I've cloned. Many of them don't have a single occurrence of substring. Please support that claim with actual data.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by GrandFather (Saint) on Sep 12, 2020 at 16:15 UTC

    If there were just one thing this thread has shown, it is how many sensible monks with good coding habits there are!

    Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by alexander_lunev (Pilgrim) on Sep 10, 2020 at 09:02 UTC

    Making Perl more like modern Python or JS is not improvement to language, you need another word for that, something like "trends" or "fashion", or something like that. I see this list as a simplification of language (and in a bad way), not improvement. As if some newby programmer would not want to improve himself, to get himself up to match the complexity of language, but blaim language complexity and demand the language complexity to go down to his (low) level. "I don't want to count closing brackets, make something that will close them all", "I don't want to watch for semicolons, let interpreter watch for end of sentence for me", "This complex function is hard to understand and remember how to use it in a right way, give me bunch of simple functions that will do the same as this one function, but they will be easy to remember".

    Making tool more simple will not make it more powerful, or more efficient, but instead could make it less efficient, because the tool will have to waste some of its power to compensate user's ineptitude. Interpreter would waste CPU and memory to comprehend sentence ending, this "new" closing brackets and extra function calls, and what's gain here? I see only one - that newby programmer could write code with less mind efforts. So it's not improvement of language to do more with less, but instead a change that will cause tool do same with more. Is it improvement? I don't think so.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by jo37 (Deacon) on Sep 10, 2020 at 17:08 UTC
    [Highly desirable] Make a semicolon optional at the end of the line, if there is a balance of brackets on the line and the statement looks syntactically correct ("soft semicolon", the solution used in famous IBM PL/1 debugging compiler).

    I feel a bit ashamed to admit that I had programmed in PL/I for several years. The reason why PL/I was so relaxed w.r.t. syntax is simple: You put your box full of punched cards to the operators' desk and you get the compiler's result the next day. If the job had failed just because of a missing semicolon, you'd loose one full day. Nowadays there is absolutely no need for such stuff.

    BTW, the really fatal errors in a PL/I program resulted in a compiler warning of the kind "conversion done by subroutine call". This happend e.g. when assigning a pointer to a character array.

    I wouldn't like to see any of the fancy features of PL/I in Perl. Consult your fortune database:

    Speaking as someone who has delved into the intricacies of PL/I, I am sure that only Real Men could have written such a machine-hogging, cycle-grabbing, all-encompassing monster. Allocate an array and free the middle third? Sure! Why not? Multiply a character string times a bit string and assign the result to a float decimal? Go ahead! Free a controlled variable procedure parameter and reallocate it before passing it back? Overlay three different types of variable on the same memory location? Anything you say! Write a recursive macro? Well, no, but Real Men use rescan. How could a language so obviously designed and written by Real Men not be intended for Real Man use?

    Greetings,
    -jo

    $gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$
      PL/1 still exists, although as a niche language practically limited to mainframes. Along with being a base for C it also was probably the first programming language that introduced exceptions as mainstream language feature. Also IMHO it is the origin of functions substr, index and translate as we know them. Compilers from PL/1 were real masterpieces of software engineering and probably in many aspects remain unsurpassed.
      https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zmainframe/zmainframe_book.pdf

      What is common between PL/1 and Perl is the amount of unjustified hate from CS departments and users of other languages toward them.

      What I think is common about both is that, while being very unorthodox, they are expressive and useful. Fun to program with. As Larry Wall said: "Perl is, in intent, a cleaned up and summarized version of that wonderful semi-natural language known as 'Unix'."

      Unorthodox nature and solutions in Perl which stems from Unix shell is probably what makes people coming from Python/Java/JavaScript background hate it.

Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by syphilis (Archbishop) on Sep 11, 2020 at 11:50 UTC
    Hi likbez,

    I personally don't care for any of the concerns you've raised, but I do commend you for your thoughts, efforts and energy.

    The one thing I would like to see is that perl starts stringifying floating point values in a sane and intelligent way, as (eg) python3 does.
    But I doubt that will ever happen, either.

    OTOH, trying to work around perl's laughable efforts in this area has provided me with many challenging and enlightening exercises ... so maybe I should just be grateful to perl for being what it is.

    Cheers,
    Rob
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by swl (Parson) on Sep 10, 2020 at 08:54 UTC
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami (Patriarch) on Sep 14, 2020 at 22:21 UTC

    Extend last to accept labels

    last already accepts labels.

    implement "post loop switch"

    That's horrible. Noone uses continue since it doesn't give access to the lexical vars of the loop, and this suffers from the same problem.

    See Donald Knuth Structured Programming with go to Statements programming with goto statements

    Perl already has a goto statement.

    That said, while I use goto regularly in C, there's no reason to use it in Perl.

      I use continue on a quite regular basis, and yes, I sometimes need an extra scope to make the lexicals accessible.


      Enjoy, Have FUN! H.Merijn
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami (Patriarch) on Sep 14, 2020 at 22:27 UTC

    Allow default read access for global variables, but write mode only with own declaration via special pragma, for example use sunglasses.

    You can do this already. But it doesn't make sense to do this instead of creating accessors.

    Allow to specify set of characters, for which variable acquires my attribute automatically, as well as the default minimum length of non my variables via pragma my

    There's a lot of problems with this. But hey, if you want this, there's nothing's stopping from writing a module that provide this "feature".

      You can do this already. But it doesn't make sense to do this instead of creating accessors.
      IMHO, accessors are way too heavy instrument. The same objection as using regex for trimming whitespace applies: sending tank division to capture unarmed village.

      Also enforcing/encouraging OO programming style where it is not appropriate is bad, unless you are a book author ;-) Anything connected with classes and instances of them requires the problem that fits this model (remember Simula-67 in which the concept was originated stems from simulation language Simula, where this is lingua franka: simulation objects typically exist in many-many instances ). It is not a universal paradigm, as some try to present it.

      This topic is actually a part of BioPerl vs BioPython debate and I think one of the reasons that Perl so far holds its own for small bioinformatic programs (say less then 1K LOC) written by researchers is that it introduces less overhead and programs written in it consume less memory while processing the same data sets (which is important for server nodes with only 128GB of RAM, which are most common for bioinformatic clusters nows -- only few "large memory nodes" have 1TB or more of RAM ). See, for example:

      • https://digitalcommons.unomaha.edu/srcaf/2013/schedule/106/
        Previous work here at UNO1 has documented that BioPerl remains the most popular bioinformatics language. Looking to expand on this, we wished to evaluate the responsiveness of BioPerl to the needs of its community. To accomplish this, we identified major revisions in the source code and then set about data mining the official mailing list. This mailing list serves as the principal interface for communication about BioPerl.
      • https://link.springer.com/article/10.1186/1471-2105-9-82/figures/3
        Speed comparison of the BLAST parsing program. Speed comparison of the BLAST parsing program implemented in C, C++, C#, Java, Perl and Python. The programs were run on Linux and Windows platforms. The input file was a 9.8 Gb file from a BLASTP run.

        Perl versus Python

        Perl clearly outperformed Python for I/O operations. Perl was three times as fast as Python when reading a FASTA file and needed half of the space to store the sequences in memory (Fig 4). From the results of the global alignment and NJ programs Python appeared to have better character string manipulation capabilities than Perl. Even though the NJ program required reading a file, where Python did not perform well compared to Perl (Fig 2), the computation of the dissimilarity matrix was actually the most discriminating task, since more than 90% of processing time was taken up by this step for every language except C, where it took up 75% of processing time.

        Python was the worst performer for parsing a BLAST file (Fig 3), taking more than 38 minutes to process the file compared to Perl, which took only 7.28 minutes. This difference did not arise from any inability of Python to handle large files, since it took only 3.2 minutes to read the file without processing the lines. Perl accomplished the same task in only 1.4 minutes.

        Perl emphasizes support for common application-oriented tasks, by having built-in regular expressions, file scanning and report generating features. Python emphasizes support for common programming methodologies such as data structure design and object-oriented programming.

      • https://www.koreascience.or.kr/article/JAKO200922951807583.pdf
        In an evaluation of individual languages, Java shows the best overall performance in most tasks in terms of both execution time and memory management BioJava effectively takes advantage of its native language, Java, unlike BioPython. Interestingly, Perl and BioPerl outperformed Java and BioJava when processing small data sets. In addition, Perl is very powerful for string manipulation, even compared to both Java and Python. According to the experimental results, the string manipulation operation in Python seems to be inefficient compared to Perl and Java, the inefficiency is also shown in the experiment by Fourment and Gillings based on the BLAST parsing program 13 On the other hand. Python seems to be better in memory management than Perl.

        Compared to other languages used in this experiment, BioPython performed very poorly for most tasks. BioPython was much slower and consumed more memory in all tasks than any other language used in this experiment. This result is surprising to us and indicates that BioPython may need a significant improvement in language implementation

        Also enforcing/encouraging OO programming style where it is not appropriate is bad

        Do you listen to yourself? Having modules provide functions is not bad.

        Besides, I said you can already do this without accessors.

        https://link.springer.com/article/10.1186/1471-2105-9-82/figures/3

        Oh hey, I've seen that link before. You're ignoring the elephant in the room: if you want speed, you need to use C. Oh, and C++ isn't very far behind so maybe it's worth using that instead because std::string is so much nicer than cstrings.

        I'm not sure what you're up to here, I see no point to any of your recommendations on Perl 7 and, worse yet, you insist on misquoting Knuth to support your position.

        Ok, I'm sorry. That probably feels like an attack. I'd like to think your heart is in the right place and that you're really trying to make Perl better. Assuming your realm is genetics, the way to make Perl faster is XS so you can use C for the speed. Micro-optimizing on $_ is not the answer.

Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami (Patriarch) on Sep 14, 2020 at 22:30 UTC

    As extracting of substring is a very frequent operation

    It's actually quite rare to want to extract a substring by position.

    Implement tail and head functions as synonyms to substr ($line,0,$len) and substr($line,-$len)

    Nothing's stopping you from doing that right now.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by ikegami (Patriarch) on Sep 14, 2020 at 22:17 UTC

    Eliminate keyword 'given' and treat for(scalar) as a switch statement.

    You can already do that.

    Disable smart marching by default.

    At this point, when is virtually an alias for if. It's rather pointless.

    Interpreter should flag as an error if no $_ used in when construct to allow optimization

    eh? How does being force to use $_ add opportunities for optimization?

      eh? How does being force to use $_ add opportunities for optimization?
      Theoretically the fact that there are several comparisons allows to make comparison to $_ with long strings faster (say more then 64 characters long). If the switch contains several "when" branches with string constants you can pre-compute hash of them and first compare a hash of $_ with hash of the constant and only if hash matches perform full comparison: you need to compute a single hash of $_ for all comparisons. If all "when" branches represent search without meta characters you can pre-compute a table via Knuth-Morris-Pratt for strings search.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by Perlbotics (Archbishop) on Sep 10, 2020 at 19:24 UTC

    I would barter all of these improvements for a less noisy but performant elemement accessor syntax:

    i.e.

    $it->{$key}->[$idx]->{section}->[$i]->{'some.doc'}->method1()->[sub1 +(5)]->method2($x); # or $it->{$key}[$idx]{section}[$i]{'some.doc'}->method1()->[sub1(5)]->me +thod2($x);

    becomes something like:

    $it->@( $key $idx section $i some.doc method1() sub1(5) method2($x) +);
    or something smarter...

    Disambiguation: If the actual element is blessed and can('method1'), it is invoked. Otherwise it is treated as a function call (:: might be used for further disambiguation).

    I.e. similar to Data::Diver, just more efficient together with a pragma or other method to control auto-vivification. Yes, I am aware, that I could build something similar as a module, but it would be pure Perl.

      Potentially ambiguous. What if $it->{$key} returns a blessed scalarref that overloads both @{} and %{}? Is the next step $it->{$key}[$idx] or $it->{$key}{$idx}?

        Good point. That's the drawback where edge-cases can add a lot of complexity.
        Perhaps throw an exception? Allow annotations on how to resolve (see below)? Implicit rules? — down the rabbit hole of smart-matching :(

        Example: Resolve overloaded @{} by using the standard notation as a hint like so?

        $it->@( $key [$idx] section $i some.doc method1() sub1(5) method2($x) +);
        It should be rarely needed.

Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by perlfan (Vicar) on Sep 10, 2020 at 14:25 UTC
    Currently, the big push is to turn on warnings and strict by default; I like the initially slow approach. I don't have a strong opinion about any of your suggestions (good or bad) because I see none of them as particularly disruptive. Heck, I'd be happy to to have say and state available without turning them on explicitly. Ultimately, I just look forward to moving towards a more aggressive model of having new features on by default.
Re: What esteemed monks think about changes necessary/desirable in Perl 7 outside of OO staff
by stevieb (Canon) on Sep 28, 2020 at 03:33 UTC

    I don't currently have the capacity to read everything. I just have one question...

    Why is it called Perl 7?

    Doesn't that seem outright ridiculous considering the fiasco of Perl 6?

    Perhaps I missed those discussions (I admit, I've been away for a bit).

    Seriously though. Doesn't anyone have any insight or forethought?

    I would like the new language be called 'FLOP'. "Fucking Language of Practicality".

      Why is it called Perl 7?
      Short version is "so that we can change the defaults". Turn on strict and warnings and enable say and so on without requiring a bunch of boilerplate use statements to enable everything that's been developed in the last decade.

      I think a lot of it is also marketing-driven, to indicate that "this is the latest Perl" and avoid managers saying "Why are you using Perl 5, when there's a Perl 6 out there?", but changing the defaults is the stated official purpose of Perl 7.

      Doesn't that seem outright ridiculous considering the fiasco of Perl 6?
      Contrary to the suggestions in the root node of this discussion, Perl 7 is supposed to only be "the latest Perl 5 with different defaults" and not a Perl 6-style complete overhaul of the language.

      There's discussion on this news thread: Announcing Perl 7

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

        I don't care anymore.

        I've been a Perl person since I knew what a keyboard is.

        All of this naming nonsense is complete bullshit.

        Why can't we just code for crying out loud, and discuss those issues? What happened to those days?

        Fucking politics. Done with it.