http://www.perlmonks.org?node_id=633641

The impending advent of perl5.10 is leading me to think about what I'd like to see in a perl5.12.

Off the top of my head:

Anybody else have ideas?

Replies are listed 'Best First'.
Re: what would you like to see in perl5.12?
by BrowserUk (Patriarch) on Aug 19, 2007 at 18:47 UTC

        I'm not quite sure what Perl6::Declare has to do with improving teh performance of sub calss in Perl5?

        Of course, that might in part be due to my being unable to find any even vague description of what Perl6::Declare does? Of the 11 links turned up by the provided Google search: 3 are in japanese (or Chinese?); 4 are links to random points in some SVN repository or another; 3 are apparently Twitter logs for someone or something called "Jaiku"; and the last is this.

        I pursued the link associated with the only mention of Perl5-Declare on that page through half a dozen or so branches, but never did find any further reference. And a cpan search turned up nothing either.

        So, if you have a better link it would be appreciated. Otherwise, a brief explanation of how adding method signatures improves performance?


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: what would you like to see in perl5.12?
by Corion (Patriarch) on Aug 19, 2007 at 20:18 UTC

    The thing that is still missing in the Perl core for me is more flow control resp. non-linear flow:

    • Generators in Perl, so I can use (say):
      sub upto { my $stop = $_[0]; my $start = 0; for ($start..$stop) { yield $_ }; }; for my $item (upto(5)) { print "At $item\n"; }; __END__ At 1 At 2 At 3 At 4 At 5

      So far, Coro implements that, but not for Win32/MSVC, and it is not that stable. Also, the libcoro that Coro uses is under the GPL, which prohibits its distribution with the Perl core.

    • Lightweight threads that have the approach of "share everything" instead of the "share nothing" approach taken by Perl so far. There is Thread::Sociable, which implements that, but so far, the approach to Perl threads has been, different. All threading is problematic in Perl because of the semantics of the really global stuff, like the namespace - if you have a "share everything" approach, you need to protect %:: and everything hanging off there, or the following code will behave unpredictable:
      sub frobnicate { print "Frobnicating\n"; }; sub frobnitz { print "Frobnitzing\n"; }; sub gargle { local *frobnicate = \&frobnitz; frobnicate(); }; my $thr1 = async { gargle() }; my $thr2 = async { gargle() }; my $thr3 = async { gargle() };
    • Transparent asynchronous IO. When I use the following:
      open my $fh, "<:async", $filename or die "Couldn't open '$filename': $!"; my $line = <$fh>; # ... do some busy work without touching $line ... print $line;

      $line should be returned as a tie'd variable and the read request should be run in the background, allowing the foreground program to continue. Any access to $line will then wait until the background read operation has completed.

    Update:Upon rereading, I don't need the :Generator syntax on my generators. Just using the yield keyword (similar to return but remember all state so we know where to continue when we get called again) is enough.

      What should:

      for my $item (upto(5)) { for my $other (upto(5)) { print "At $item and $other\n"; }; };
      mean? And how do I do the other? Can you give me an example where this will actually be usefull? And that can't be done better using closures.

      Share-everything threads were tried in perl 5.005.

      tie is slow. In either case you should already be able to implement this using PerlIO::via. If enough people use that, we might consider adding that to core.

        I think that upto(...) returns an iterator/generator. The example I used is fairly trivial to reimplement in Perl5 now already:

        # perl 5.10 sub ENDOFITERATION { undef }; # some magic value that signals the end +of all values sub upto { my $start = 0; my $stop = shift; return sub { if ($start < $stop) { return $start++ } else { return ENDOFITERATION }; }; };

        Iterators/generators allow you to conveniently program in a linear fashion without needing to maintain the state. For example this contrived example is far easier to write in a linear fashion than it is in a closure fashion, because you need to store the current point of execution:

        # Read incoming commands - an infinite loop/generator sub get_commands { while (<>) { yield $_; }; }; sub user_session { COMMAND: { my $command = get_commands; # read one command if ($command =~ /^login (\w+)/) { my $user = $1; my $pass = get_commands; # read next line if ($user_db{$user} ne $pass) { print "User $user rejected.\n"; redo COMMAND; } else { for my $command (get_commands) { if ($command =~ /^logout/) { return } else { yield [$user, $command] }; }; }; } else { # not logged in }; }; }; sub process_sessions { for my $line (user_session()) { my ($user,$command) = @$line; print "$user: Executing $command\n"; }; };

        I'm aware that all my wishes are possible in principle now already, but either slow or burdened with ugly syntax. Which is why I wish for them to become less burdened and faster.

      The thing that is still missing in the Perl core for me is more flow control resp. non-linear flow:

      One thing that I miss both in Perl 5, 6 and most languages I know of is some form of addomesticated code rewriting. We're all told that goto is evil. But we have some forms of addomesticated goto: next, last and redo, which are not evil. We're all told that code rewriting is evil. But I'm sure that there could be useful and not evil forms of code rewriting. Limbic~Region speaks about that in Doing "it" only once.

        START blocks provide "do once" capability in Perl 6.
Re: what would you like to see in perl5.12?
by duff (Parson) on Aug 19, 2007 at 19:48 UTC

    Personally, I'd like to see some of the features of Perl 6.

    • Real subroutine signatures
    • pipe-line operators (i.e. ==> and <==)
    • The reduce operator
    • Implicit variable declaration via twigil ($^foo)
    • Better support for OOP
    • Perl6 Regex
    Et cetera.

    It doesn't have to be perfect or exactly like Perl 6, as long as it provides a good cognitive bridge.

      The Perl 6 features I'd like to see most in 5.12 is optional static typing, and real subroutine/method prototypes, a la

      sub repeat(Str $string, Int times)

      That makes code very much self-documentatory, and perhaps the partial statitic typing allows for more optimizations.

      Mind you, I have now idea if that's implementable with the current compiler/interpreter design - it's just a wish ;-)

        Bump the Moose suggestion and you can get close to that functionality now...
        use Moose; has 'string' => ( isa => 'Str', is => 'rw' ); has 'times' => ( isa => 'Int', is => 'rw' ); sub foo { my $self = shift; my ( $string, $times ) = ( $self->string, $self->times ); }


        Evan Carroll
        www.EvanCarroll.com

        Why would anyone want to repeat the failed experiment of prefix types?  sub foo( Str $ref->[]{}, Int @arr[], Str $fun(Int bogus, Real otherbogus)) anyone?

Re: what would you like to see in perl5.12? (trees)
by tye (Sage) on Aug 20, 2007 at 02:50 UTC

    An efficient sorted hash that you use just like a hash but that is implemented as a balanced tree (sorted by key strings). I'm so tired of working around not having this or just using a different language in order to get it (most other languages have it).

    The only script-visible changes would be the module you include to say you want sorted hashes and the function it exports so you 'seek' the each operator.

    - tye        

      The only script-visible changes would be the module you include to say you want sorted hashes
      It'd make more sense to me to have a :btree attribute on the hash declaration (does that mean lexical hashes only? maybe). Would the attribute take an optional comparison function?
      and the function it exports so you 'seek' the each operator.
      I'd put that in Hash::Util. Is that seek to a particular key value, or seek to key N?

        It'd seek to a particular key value. There are certainly trees that would also allow seeking to a particular index. I don't care whether there is a way to override the default comparison function (just cmp).

        Yes, using an attribute for this would be fine.

        Update: s/<=>/cmp/.

        - tye        

      I've added seekable and reversible hash iteration to Tree::RB. Here is an example:
      use strict; use warnings; use feature 'say'; use Tree::RB; my $tied = tie(my %capital, 'Tree::RB'); %capital = ( France => 'Paris', England => 'London', Hungary => 'Budapest', Ireland => 'Dublin', Egypt => 'Cairo', Germany => 'Berlin', ); say 'Countries starting from Germany:'; $tied->hseek('Germany'); while(my ($key, $val) = each %capital) { say "key: $key, val: $val"; } say "\nCountries in reverse:"; $tied->hseek({-reverse=> 1}); while(my ($key, $val) = each %capital) { say "key: $key, val: $val"; }
      Output:
      Countries starting from Germany: key: Germany, val: Berlin key: Hungary, val: Budapest key: Ireland, val: Dublin Countries in reverse: key: Ireland, val: Dublin key: Hungary, val: Budapest key: Germany, val: Berlin key: France, val: Paris key: England, val: London key: Egypt, val: Cairo
      What should the 'seek' function do if you seek to a non existent key?

        'seek' doesn't care whether the key exists or not. It just arranges for the next use of each (actually, adding a way to reverse 'each' would be prudent as well) finds the earliest key greater than or equal to the key given to 'seek'. For convenience of interface, 'seek' might return something which might be different depending on whether the requested key exists or not, but those are details best left to the (unknown) implementor.

        - tye        

Re: what would you like to see in perl5.12? (attributes)
by lodin (Hermit) on Aug 19, 2007 at 22:40 UTC

    A solid, complete implementation of attributes. Luckily, attributes are marked experimental.

    Here's the issues I think need to be addressed, in a fuzzily sorted order of importance.

    • Namespace scoping: This is fundamental. No more attributes in UNIVERSAL. It should be as easy to import/export attributes as variables and subroutines. Without it you can't release any general purpose attribute modules on CPAN that other module authors can re-use. They'll only be useful in-house where you can control they won't conflict with each other. Back in 2005 26 of 28 modules (that I found) on CPAN that provided attributes polluted the UNIVERSAL namespace.
    • A unified implementation: The simple FETCH_/MODIFY_*type*_ATTRIBUTES methods implementation is just begging for trouble. It works for systems like Catalyst, but not as a general language feature.
    • True attribute arguments: my $foo : Foo(foo => 'bar'); should work. The parenthesis shouldn't be a single quote yielding a string ("annotation"), but provide arguments to the implementor.
    • A working way to store attribute metadata: After my $foo : Foo;, how do you know that $foo is decorated with Foo?
    • Better/working subroutine attributes: Subroutine attributes should be able to "redefine" the subroutine. (Currently, named subroutines are not fully defined when MODIFY_CODE_ATTRIBUTES is called.) No more broken INIT workarounds. Anonymous subroutine attributes have no chance at all to modify the subroutine (or return another subroutine, wrapping the original). my $foo = sub :Memoize { ... }; cannot be written.

    Some two years ago I wrote a note about why I think the current implementation of attributes is broken. I also wrote about a set of modules that would solve some of the issues. While I believe it was a better implementation than the alternatives it didn't overcome the major obstacles as they require changes in the perl source. So I put that work back on the shelf. In real life this is a "redo and do it right" subject.

    I still believe there's a lot of potential in attributes, if only implemented properly.

    Update: see Namespaces and importing/exporting of attributes for a concrete idea of a possible improvement.

    lodin

      I still believe there's a lot of potential in attributes, if only implemented properly.
      First have a look at how properties and traits are completely unified with object attributes and roles/mixins in Perl 6, which pretty much covers all of your points without thinking of attributes as a separate facility. I have this crazy notion that "implemented properly" must be preceded by "designed properly", you see... :-)
        Right, but I don't know that Perl 5 has the luxury to do any better than "designed well enough".
Re: what would you like to see in perl5.12?
by bart (Canon) on Aug 20, 2007 at 11:45 UTC
    First of all, the things that are promised for 5.10. :) These include:
    • defined or: // and //=
    • speed improvements in regexes as promised (and implemented) by demerphq
    • recursive regexes! (ditto)

    Aside from that, I'd like to see support for matching regexes across boundaries for partially loaded buffers. That would ease processing files in blocks of a few k each, instead of having to load the entire file into a string.

    As an example: say you're looking for a word "SELECT" and the buffer contains:

    my $sth = $dbh->prepare('SEL
    It's possible that it would have matched "SELECT" if the buffer wasn't cut off.

    I'd like regexes to be able to catch that. Automatically.

    I don't really care how it's done, but I personally favor a system that takes some action (die, set a variable, call a callback sub) when the lookahead "touches" the back end of the buffer. (I call that the "electric fence" approach: touch it and you're dead.)

      Yes. I do agree completely. This opens the realm of stream regexps and would facilitate greatly the construction of regexp-based tokenizer (scalar m//gc) which need to process their input in chunks. Currently you need to resort to contorted hacks to do stream tokenizing, a pity as this limits the implementation of generic parser generators in pure Perl.

      What is needed is a way to keep the state of the regexp engine at the end of the buffer -- end-of-buffer-match case--, so that when you add another chunk, the engine does not start again from the beginning. Considering all the goodies added by demerphq, maybe there is hope ;) to see something soon.

      Also I'd like to be able to switch to a smaller but faster regexp implementation just for a block. Or maybe be able to turn off parts of the main engine -- locally -- that I know I am not going to use in a given block (supposing that doing so gives extra speed of course).

      cheers --stephan
Re: what would you like to see in perl5.12?
by holli (Abbot) on Aug 20, 2007 at 12:34 UTC
    "Real" and fast lvalue-subs that are able to "see" the right value (for checking), not the crippled implementation as today.

    Yes, this is for accessors like $object->foo = "bar";, I grew up with VB and $object->foo("bar";) simply doesn't feel right.

    I know it can be done by returning tied hashes, but that is fat, slow and ugly and needs extra work. Thinking about it, why not a new keyword:
    package blablabla; sub new { #... } property get foo { return $self->{_foo}; } property set foo { my $foo = shift; $self->{_foo} = $foo; }


    holli, /regexed monk/
Re: what would you like to see in perl5.12?
by FunkyMonk (Chancellor) on Aug 19, 2007 at 22:23 UTC
      Ugh. If you're writing enough code for strict and warnings to be useful, then adding "use strict;\nuse warnings;\n" to the top shouldn't be too hard. Fortunately, the people who have enough skill to modify the Perl core don't share your opinion.
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: what would you like to see in perl5.12? (nested statement modifiers)
by ysth (Canon) on Aug 21, 2007 at 06:12 UTC
    Nested statement modifiers are reportedly rejected by Larry for Perl 6, so presumably ruled out of court for Perl5 as well. Poking around shows this thread about a year ago, with someone citing Larry rejecting them 5 years ago.

    If indeed this is final, all I can say is "too bad". I think all the arguments against multiple statement modifiers apply equally to single statement modifiers. And you may call it "enough rope", but rope can be awfully handy at times. If I have time, I may dig up a couple of examples where I would have used them, and people can laugh at me.

    Update: another couple of Perl 6 threads, from 2003: Statement modifiers, Statement modifiers (yes, again)

      Nevertheless, Rule 2 applies here: several months ago we decided it was okay for Perl 6 to allow a conditional modifier inside a loop modifier because it makes it easier to write list comprehensions close to the way mathematicians like to write them:
      %desc{$_} if .path for <n ne e se s sw w nw up down>
      Also, any parenthesized or bracketed expression is now parsed as a statement, so you can nest modifiers to your heart's content as long as you parenthesize. In particular, this allows you to use a list comprehension for a slice subscript.

      Update: changed @desc to %desc as noted by wolverian++

      Actually, the main reason Perl5 doesn't have nested statement modifiers is that noone submitted a patch for it.

      About the only way to get your wish into Perl5 is to actually go do it. A single person writing a patch for nested modifiers increases the chance to get it added to Perl a million times more than a thousand perlmonks wishing for it in a thread.

        In many cases, I'd agree with you. This, though, is something people seem to have a real hangup over. The patch is pretty trivial (albeit writing tests is less so). But now that Larry has changed his mind, it should be an easier sell. (pause). There, the perly.y changes took about 45 seconds. Anybody want to help write tests?
Re: what would you like to see in perl5.12?
by blazar (Canon) on Aug 21, 2007 at 10:16 UTC

    Two things that I would like, interrelated each other, are:

    • lexical subs;
    • a Perl 6 like magic package to access the lexical pad.

    Of course in Perl 5 it would be more of an interface thingie, while in Perl 6 AIUI it would be a more "substantial" thing.

Re: what would you like to see in perl5.12?
by sri (Vicar) on Aug 19, 2007 at 21:21 UTC
    A real working version of Sub::Uplevel and maybe some more control over the call stack (context objects?). :)

    Example:
    package main; my $i = 23; &Foo::test(); package Foo; sub test { my $context = uplevel_context(); eval('print $i', $context); }
Re: what would you like to see in perl5.12?
by CountZero (Bishop) on Aug 20, 2007 at 15:04 UTC
    A new pragma: "use perlmonks qw/to solve my programming problem/;"

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Re: what would you like to see in perl5.12?
by Codon (Friar) on Aug 21, 2007 at 07:33 UTC
    The nested modifier, while it may have already been rejected, could have some tidy little uses.
    s/foo/bar/ for (@these) if ($this);
    I suppose that could be accomplished as
    map { s/foo/bar/ } @these if ($this);
    but is that as clear as the first statement? Using map in void context to get the effect of a for seems clumsy.

    As for something I'd really like to see, interpolation of method calls in a string.

    print "The 'bar' attribute of object 'foo' is $foo->bar();\n";
    As it is, I get to do the oh-so-readable
    print "The 'bar' attribute of object 'foo' is @{[ $foo->bar() ]};\n";
    That doesn't look like it should work, but it does.

    While I'm on the concept of OOP, I think I'd like to see Perl actually implement some form of strong encapsulation for objects "out of the box" as opposed to having to roll your own or re-use your "tried and true" method, whatever that may be (CPAN or home-grown).

    Certainly the "defined or" (dor) functionality would be a serious benefit to prevent warnings in my code.

    That's about all I can think of at this late hour. Time to sleep.

    Ivan Heffner
    Sr. Software Engineer
    WhitePages.com, Inc.
Re: what would you like to see in perl5.12?
by EvanCarroll (Chaplain) on Aug 19, 2007 at 19:45 UTC
    Good meditation! Here is my wishlist:
    • Moose made part of the standard distro, and a perl switch to turn it on.
    • A totally new documentation format, can we all just agree pod sucks... It's so old and dated. It comes off as a markup that was made for documenting the intention of code as to eliminate the need to comment-explain in source. It is instead used for writing verbose tutorials that sit uncomfortable and awkwardly in the middle of source.

      My solution would be some sort of wiki-powered pod, to which perldoc could sync to and read from the online Wiki. I'm not saying this wiki needs to be anon; and, I'm not putting any stipulations on its implementation. It should probably start off as an RFC right about now. Community powered, centralized documentation would ensure that perl stays a leg up on the doc component of the language, and it would alleviate the devs needs to doc everything. So often I find myself debunking bad docs, and then too lazy to push up an elaborate patch in the current sub-par format. I should clarify the word "doc" in this paragraph is a reference to tutorials, how-tos, use cases etc., not mere internal explanation. It is also my personal opinion that Textile is a superior markup to pod.

      As to the archaic pod, I think it serves a good purpose documenting code, but one feature I would like to see in it is the ability to further notate what the code chuck is you're documenting. I don't want to have to keep a sub in sync, inside of a pod block.

      Bottom line: Tutorials should not be in pod. They are not pod material, they are too often an interference to the terseness of perl. Put them online, and let's let the community take a crack at detailing the use of the code, and leave POD to the internal function of the code and dev-notes, i.e., what in most other languages is known as *comments* (as compared to "the documentation").

    So thats my two cents, the two things I see perl5 most inept in can be almost totally fixed with the inclusion of Moose, and a better documentation system. (though I know how well accepted any criticism of pod will be)



    Evan Carroll
    www.EvanCarroll.com
      I agree with the inclusion of Moose, but disagree with pod-bashing. :-)
      []s, HTH, Massa (κς,πμ,πλ)
    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: what would you like to see in perl5.12?
by moritz (Cardinal) on Aug 21, 2007 at 11:24 UTC
    I don't know what's the state of assertions in 5.10, if they are not implemented I'd like to see some kind of assertion mechanism in 5.12.

    You should have the possibilty to disable assertions via a pragmatic use or a command line switch with virtually no performance impact.

    Usefull assertions are imho plain assert $code_that_evals_to_true; and pre- and postconditions for subs and methods.

    In the case of methods it would be usefull if the pre- and postconditions were inherited to all child classes (see PRE/POST in S06 for the corresponding p6 spec).

Re: what would you like to see in perl5.12?
by BrowserUk (Patriarch) on Aug 21, 2007 at 23:47 UTC

    This reminded of another one that I've wanted on several occasions, and seen come up here a few times also.

    • A vec that can manipulate any number of bits (at least up to the machine native ulong size), at any offset.

      So, vec( $bits, 30, 5 ) = 31; would do the right thing.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: what would you like to see in perl5.12? (require $class)
by ikegami (Patriarch) on Aug 22, 2007 at 19:24 UTC
    my $class = 'HTTP::Request'; require $class;
      This is a good idea. It's backwards incompatible (in the case where someone really wanted to search @INC for a file named 'HTTP::Request'), but it seems to me within the level of incompatibility that's acceptable for a full version number change. (Though YMMV.)

        Do you mean %INC? Changing %INC to match is not required, and I wasn't suggesting that it should be done. People who want to search %INC (or @INC) can continue to do the same class to path conversion they are already doing.

        But if you wanted to change %INC to class names, you could maintain compatibility with old scripts by placing both the class name and paths in %INC.

Re: what would you like to see in perl5.12?
by Joost (Canon) on Aug 21, 2007 at 23:52 UTC
    prototypes on methods, so that I can do
    $obj->do { stuff(@_) }

    hey, a man can dream :-)

    update: ysth wanted to know what the prototype for my example was. I'll explain.

    First, I'll note I posted this originally because the OP made me think of Re: Automatic Loop Counter not in perl. But that may not be clear enough.

    So, anyway, one of the things I do quite a lot is pass around code blocks (or anonymous subroutines subroutine references - in perl it's all the same - as, as far as I'm concerned, it should be)

    That means I do a lot of stuff like

    $object->method(sub { my ($arg) = @_; # stuff });
    Which just looks ugly. Especially when compared to
    @result = map { insert(@your_code_here) } @input;
    or even
    sub one_hundred_and_one_times(&) { my $block = shift; $block->() for (0 .. 100); } @result = one_hundred_and_one_times { more($stuff) };
    Sadly, that doesn't work for methods, since method calls ignore prototypes.

    In other words, I'd just like

    $object->method { # code block };
    to pass "sub { # code block }" to "$object->method()" if "method" is declared with a "&" prototype.

    updated fixed syntax in example.

      That impact of prototypes requires compile-time knowledge which means that this proposal would require compile-time binding of a interface to the scalar variable that will hold the object (and run-time checking that any objects assigned to that scalar implement that interface).

      So this would only be possible with the use of attributes on variables. But that also limits the cases when it works. For examlpe, you could not get a prototype to be in effect for more complex code like $group->get($x)->runcode { ... } unless there was a way to compile-time declare that the variable $group must always implement an interface that includes a get() method that returns an object that always implements an interface that has a runcode(&) method. And you see how complicated that quickly gets.

      For other than the simplest case (calling methods directly via a scalar variable) you need to add a whole lot of static analysis abilities to the Perl compiler.

      I'm not saying that any of this is impossible, or even that it will never happen, but I think it is worth knowing a bit of what would be required.

      - tye        

Re: what would you like to see in perl5.12?
by Jenda (Abbot) on Aug 20, 2007 at 14:57 UTC
    • I don't think nested modifiers are a good idea. The result would be too complex and hard to read. If you need two "levels", change the outer one to an ordinary loop or conditional statement.
    • I don't do thinks like this, but it might be handy. It wil make parsing harder again though so I doubt it will be implemented.
    • That looks like a neat idea.

      Why would nested modifiers be too hard to read? Billions of people around the world manage it on a daily basis, in human languages.

      I, for one, am constantly frustrated by the fact that simple, perfectly readable things like

      print if /foo/ while <$fh>

      don't work. This to me is more intuitive than either of the alternatives, namely

      /foo/ and print while <$fh>

      which messes up the order of operations, or

      while (<$fh>) { print if /foo/ }

      which is certainly clear, but just looks cluttered with all that extra punctuation.

      Your argument that nested modifiers would be hard to read is weakened by the fact that the "and" version, which is supported today, is by far the least readable of the three. I'm sure I'm not the only average Perl hacker who has to think twice to be certain that the "while" and "and" will be evaluated in the correct order...

        Well, do they? Double modifiers remind me of the Monthy Pythons The Meaning of life scene in school

        Now before I begin the lesson will those of you who are playing in the match this afternoon move your clothes down on to the lower peg immediately after lunch before you write your letter home, if you're not getting your hair cut, unless you've got a younger brother who is going out this weekend as the guest of another boy, in which case collect his note before lunch, put it in your letter after you've had your hair cut, and make sure he moves your clothes down onto the lower peg for you. Now...

        The "and" version is certainly supported, but I would not consider it the recomended version.

        There are already people that disapprove the use of statement modifiers completely, I would not go that far, but I'd only recomend using them if both the statement and the modifier is fairly simple.

Re: what would you like to see in perl5.12?
by blazar (Canon) on Aug 20, 2007 at 19:57 UTC
    Nested statement modifiers (e.g. EXPR1 if EXPR2 for LIST instead of EXPR2 and EXPR1 for LIST)

    That is not going to happen: the idea was firmly rejected by $Larry when it was suggested for Perl 6. Although occasionally I've cherished the idea, it's "kinda too much" for me too.

    Method names given as expressions ($foo->do{ EXPR }(LIST) instead of my $tmp=EXPR; $foo->$tmp(LIST) or $foo->${\(EXPR)}(LIST))

    While I desired that too, but I can't think of a syntax that would be unambiguous:

    • $foo->do{ EXPR }(LIST) could be a regular method call. And do is already a (overloaded) keyword. What if one has a do() method?
    • $foo->{ EXPR }(LIST) could be a hash dereference;
    • $foo->( EXPR )(LIST) could be a sub dereference. And that ")(" is, well, ugly.
    Attributes on packages (allowing e.g. package Foo:extends("Bar"))

    Well, this would be cool. Wait! I still have to learn how to use attributes on subs... Oh well!!

      Method names given as expressions ($foo->do{ EXPR }(LIST) instead of my $tmp=EXPR; $foo->$tmp(LIST) or $foo->${\(EXPR)}(LIST))
      While I desired that too, but I can't think of a syntax that would be unambiguous:
      I couldn't come up with any case where ->do{ was ambiguous. It's currently a syntax error.
        I couldn't come up with any case where ->do{ was ambiguous. It's currently a syntax error.

        I hadn't considered the curlies: I had seen them but kinda not really noticed them. (It's been a terribly hard day.) If I take the curlies into account I get a very "unorthogonal" deviation from all the rest of Perl syntax I can think of. A bareword, with curlies next to it. And should whitespace be allowed between them? Or is do{ to be thought of as a single glyph? Anyway you think of it, it's very ugly.

Re: what would you like to see in perl5.12?
by blazar (Canon) on Dec 20, 2007 at 16:32 UTC
    The impending advent of perl5.10 is leading me to think about what I'd like to see in a perl5.12.

    I personally believe that it's now late to add to this thread, but I'm trying with a few interrelated ideas off the top of my head:

    • hash slices, such that %hash{@keys} has the same semantics of
      %{{ map { $_ => $hash{$_} } @keys }}
    • on a more daring basis, hash-like slices of an array, such that %array[@nums] has the same semantics of
      %{{ map { $array[$_] => 1 } @nums }}
    • on an even more daring basis, hash-like dereferencing of an arrayref, such that %{\@array} has the same semantics of
      %{{ map { $_ => 1 } @array }}

    So, to test whether $element is in @array one may check ${\@array}{$element}.

    (Moreover, these "conversions" may be optimized under the hood.)

    --
    If you can't understand the incipit, then please check the IPB Campaign.
Re: what would you like to see in perl5.12?
by bennymack (Pilgrim) on Aug 21, 2007 at 16:09 UTC

    How about some way to inline subroutines at compile time. Sort of like other compile-time optimizations but with a little added smarts. "use constant" will currently inline a sub ref which is good and pretty fast. But it seems like it would be even faster to turn the inlined sub ref into a do block.

    $ perl -Mstrict -Mwarnings -MO=Deparse -e ' use constant FOO => sub { join( shift, @_, ); }; printf( "%s\n", FOO->( ", ", 1 .. 10, ), ); ' use constant ('FOO', sub { BEGIN {${^WARNING_BITS} = "UUUUUUUUUUUU"} use strict 'refs'; join shift @_, @_; } ); BEGIN {${^WARNING_BITS} = "UUUUUUUUUUUU"} use strict 'refs'; printf "%s\n", sub { join shift @_, @_; } ->(', ', 1..10); -e syntax OK

    Wouldn't it be nice if that were turned into this instead?

    perl -Mstrict -Mwarnings -e ' printf "%s\n", do { local @_ = (", ", 1..10); join shift @_, @_; }; '

    Update: Added benchmark so people can debunk/prove the need for this.

    Update: Looks like I had the benchmarks backward and that a sub ref is actually faster than a do block. So, nevermind...

    #!/usr/bin/env perl use strict; use warnings; use Benchmark(); Benchmark::cmpthese( -1, { sub_join_1 => sub { sub { join shift @_, @_; }->( ", ", 1 .. 100 ); + }, do_join_1 => sub { do { local @_ = ( ", ", 1 .. 100 ); join shift + @_, @_; }; }, } ); __END__ $ perl bench_do_sub_1.pl Rate do_join_1 sub_join_1 do_join_1 17935/s -- -73% sub_join_1 66991/s 274% --
Re: what would you like to see in perl5.12? (bit shift strings)
by tye (Sage) on Aug 21, 2007 at 19:44 UTC

    Just a small thing: Have << and >> work on strings.

    - tye        

      oh! yes please! I forgot about that limitation, but I've hit up against it before.
      That would be nice, yes. There's a proposal on the books to have a pragma to enable this.
        <joke> There'd have to be a @{^carry} "register" to hold bits left-shifted off the front. </joke>
Re: what would you like to see in perl5.12? ($foo->do voodoo)
by Roy Johnson (Monsignor) on Aug 22, 2007 at 20:23 UTC
    Seems like you could roll your own UNIVERSAL::do to get pretty close to your second want.
    use strict; use warnings; package UNIVERSAL; # Couldn't decide which syntax would be more likeable. sub do { my $ob = shift; my $method = shift; $ob->$method(@_); } sub do2 { my $ob = shift; my $method = shift; sub { $ob->$method(@_) }; } package U; sub voo { my $ob = shift; print "Called with @_\n"; } sub new { return bless {}; } package main; my $foo = U->new(); $foo->do('v'.'oo', 1..3); $foo->do2('v'.'oo')->(1..3);
    Not really profound, but it gives me an excuse to say, "Now go do that $foo->do that U::do so well!"

    Update: lodin points out that this is pretty close to UNIVERSAL::can. Which it is. Except you'd have to put the object back in the arg list:

    $foo->do2('v'.'oo')->($foo,1..3);
    Ugh.

    Caution: Contents may have been coded under pressure.
Re: what would you like to see in perl5.12?
by syphilis (Archbishop) on Aug 26, 2007 at 12:49 UTC
    Nude centrefolds !! ... dammit, I've been wanting to post that for nearly a week now ...

    Cheers,
    Rob (who can't believe that he finally succumbed to the temptation)
      I just hope you're pinup of choice isn't Larry.


      holli, /regexed monk/
        No interest in Larry, not even interested in Moe - but Curly ... that's getting closer to the mark :-)

        Cheers,
        Rob
Re: what would you like to see in perl5.12?
by Tux (Canon) on Dec 21, 2007 at 07:39 UTC
    • Fully functional Tie::Handle. And yes, that would also include format/write.

    Enjoy, Have FUN! H.Merijn
Re: what would you like to see in perl5.12?
by Anonymous Monk on Aug 26, 2007 at 19:51 UTC
    Interesting thread, but seriously, is perl 5.12 going to be here sooner than perl 6?
      I hope not, but don't understand why you ask.
Re: what would you like to see in perl5.12?
by blazar (Canon) on Aug 26, 2007 at 12:36 UTC

    A late addition: the ability to put into @ARGV scalar and typeglob references in such a way that

    • the former ones would be opened in memory;
    • the latter ones will be used if the corresponding handle is open for reading. (Or else an error will be issued.)
Re: what would you like to see in perl5.12?
by BrowserUk (Patriarch) on Aug 26, 2007 at 19:58 UTC

    1. lock as an lvalue sub that only locked for the duration of the current statement (not block) when used as an lvalue.

      Hence

      ... lock( $var )++; ..
      would be a safe and concise substitute for
      ... { lock( $var ); $var++; } ...
    2. Also share( @array ) = ( some list ); would be nice.
    3. And a share() that didn't wipe the var being shared, but rather operated recursively on its contents.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: what would you like to see in perl5.12?
by BrowserUk (Patriarch) on Aug 21, 2007 at 05:28 UTC
    • The ability to (simply) interpolate a hash into a string.

      Perhaps using "some stuff %{hash} more stuff"; producing the same effect as print 'some stuff ' . %hash . ' more stuff';

      I would guess that syntax will be undone for backwards compatibility reasoning, though I would think that the combination %{\w+} would be fairly rare.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Forget that ... what would be really nice would be the ability to interpolate *anything* into a string. As in Perl 6:

      print "Hello, my name is {some_expression_generating_name();} and I'm +here to help.";
      Sure, it makes the curly braces special, but that's a small price to pay compared to the benefit IMHO.

        Actually yes. That would solve this problem, and several other similar ones.

        Given that whatever was put in place would have to remain notionally backwards compatible--which probably means any new interpolation mechanism is a non-starter but---I'd probably go with:

        "some stuff {{ any perl expression here }} more stuff"

        Indeed, if I'd been spec'ing Perl 6 interpolation, I think I would have removed all other interpolations in favour of a single 'interpret the block and substitute whatever it produces in its place' construct.

        It mildly complicates the simple case " xxx{{ $var }}xxx" instead of "xxx${var}xxx", but in the general case, it would be no more complicated than "xxx@ary[]xxx" or "xxx%hash{}xxx", and the consistancy would greatly simplify the parser.

        Indeed, the parsing would become simple enough that most editor syntax highligher parsers would probably be able to pick out embedded interpolation blocks, making them stand out from the surrounding string, and even highlight the embedded code in the usual manner.

        For me, the ability to have my editor highlight interpolations, (without resorting to running a second OS as an editor:), would more than make up for the slightly less convenient syntax it would require for the simple case.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
      Perhaps using "some stuff %{hash} more stuff"; producing the same effect as print 'some stuff ' . %hash . ' more stuff';

      Are you sure? Do you know what the value of a hash currently is in scalar context?

      campari:~ [11:27:54]$ perl -MData::Dumper -le 'print "<" . %INC . ">"' <5/16>
      Do you have a use case in mind? Given the lack of order of keys and the alternation of keys and values, I can't come up with one.

        The really simple one of checking what is going on in the hash when debugging.

        It would be even better if the formatting was a little more sophisticated than just a space separated list. Say key1:value1 key2:value2 key3:value3, but that's a nicety.

        Just as with the default interpolation of hashes in Perl 6, if you need more sophisticated layout, sorting etc. then it's back to rolling your own or using a dumper, but sometimes you just want a quick check. Currently I would use the "@{[ %hash ]}", but a simpler syntax would be good if it could be made to work.

        No biggy, but the thought crossed my mind.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
      Wouldn't that break lots of (s)printf formats?

      Ordinary morality is for ordinary people. -- Aleister Crowley

        As I originally proposed it, I don't think it would. In any legal printf format, % is followed one of %*+- #csduoxefgXEGbpniDUOF\d..

        Which I think means that %{...} would not conflict with any existing formats, and would generate: Invalid conversion in printf: "%{" if it appeared in any existing code. The lack of backwards compatibility issues is the nice thing about that original proposal. Albeit that I'd extend/mutate my original proposal to encompass some of the further discussion it generated.

        It can easily be extended to make %{...} a generic, interpolate whatever is inside this embedded code block and convert the result to a string in the default manner.

        And that could further be extended in a manner in keeping with normal printf rules so that it can become: %fw.p{...} where the f, w & p follow the same rules for flags, width & precision as are applied to the standard s specifier.

        To simplify: %fw.p{xxx} acts pretty much like:

        printf "%fw.ps", "@{[xxx]}"

        The code xxx is evaluated, the result converted to as string, and the string substituted as if %s had been used.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: what would you like to see in perl5.12?
by BrowserUk (Patriarch) on Aug 07, 2008 at 23:52 UTC

    Here's a couple of related new ones that fall out of something I'm working on:

    • The ability to pass anonymous blocks to subroutines in positions other than the first.

      Ie. Drop the requirement for the sub keyword. Possibly only if the recipient sub is prototyped to take sub references: eg.

      sub someSub (&&&) { my @coderefs = @_; ... }
    • The ability to pass bare expressions as parameters to user subs.

      In the same way as map & grep can take an expression that is executed repetitively within the context of the function: eg: @array = map sqrt( $_ ), 1 .. 10;

    I've no idea if either is actually feasible, but if you don't ask, you'll never know.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: what would you like to see in perl5.12?
by renodino (Curate) on Aug 19, 2007 at 21:25 UTC
    iCOW.

    Update: Persistent --XP on this, but no explanations. So either

    • people don't know what iCOW is (ithreads Copy On Write) OR
    • people don't want faster thread spawn times and reduced thread footprint.

    Maybe Intel, AMD, IBM, and Sun aren't banging on the table loudly enough ?


    Perl Contrarian & SQL fanboy
Re: what would you like to see in perl5.12?
by blazar (Canon) on Aug 26, 2007 at 14:39 UTC

    Another late addition from a previous idea: bring some functionality from Scalar::Util into core ref by having the latter return, in list context, respectively: REF, ADDR, BLESSED, where

    • REF would be ref()'s current output if the reference is not blessed, and if it is then the same as if it were not,
    • ADDR the same as refaddr()'s and
    • BLESSED the package the reference is blessed in, if it is, or undef otherwise.
      Hmm. Not sure that would be worth it, given the possibility of foo(ref($bar), "baz"), etc.

        Yes you're perfectly right. One should see how much existing codebase is affected. Perhaps it should have been there from start. In any case I can see that p5p would hardly risk even if they found the feature as desirable as I do. But... if that's "what I would like to see in Perl (5.12)" ... well, this is one such thing!

Re: what would you like to see in perl5.12?
by blazar (Canon) on Aug 15, 2008 at 08:23 UTC

    I personally believe and hope that this node can be considered as an "ever active one" so I won't clutter Meditations with this "new" idea of mine like I've been tempted to do, but post it as a followup here...

    Well, here's my modest proposal re join: if the first argument passed to it is a reference, then it should not stringify it (which is unlikely to ever having been useful, and thus should not break any backwards compatibility) but

    1. if it is a hashref of the form { first => [LIST], then => [LIST] } then it should join the first items on the 'first' list and the remaining ones on the 'then' one, cyclically; for maximum dwimmery, if keys other then these (or better chosen ones, but these sound reasonable) are given, the first two in alphabetic order (which does make sense) would be used; if any key is missing, then the corresponding LIST would be treated as empty;
    2. if it is an arrayref $arr, then it would behave as if it were {then => $arr};
    3. if it is a subref then the subref would be called each time, with no arguments and its return value would be used to join on;
    4. if it is a scalar or glob ref, then I can't imagine any particularly good semantics; and if it is a blessed ref, then... I was thinking of making it check for especially named methods like 'action' (corresponding to the sub case above, and possibly taking precedence,) 'first' and 'then' but probably it would be better to just leave the object stringify the way it prefers and not deviate from the current behaviour.
    --
    If you can't understand the incipit, then please check the IPB Campaign.
Re: what would you like to see in perl5.12?
by Bloodnok (Vicar) on Dec 31, 2008 at 14:44 UTC
    How about a soundex style help to extend the diagnostic reported when an attempt to use/require a module fail because the referenced module name is slightly mis-spelt e.g. typing use Image::Magic; instead of use Image::Magick resulting ?

    Just my penn'orth

    A user level that continues to overstate my experience :-))
Re: what would you like to see in perl5.12?
by BrowserUk (Patriarch) on Jan 12, 2009 at 07:21 UTC