http://qs321.pair.com?node_id=437860


in reply to (Sort of) poll: what Perl6 features do you consider {likely,desirable} to leak into P5?

I would definitely love to have a native given expression today. It does not mean that I believe it's likely, but certainly it's highly desirable.

given EXPR { when EXPR { ... } when EXPR { ... } ... } my sub get_data ($data) { given $data { when /^\d+$/ { return %var{""} = $_ } when 'previous' { return %var{""} // fail NoData } when %var { return %var{""} = %var{$_} } default { die Err::BadData : msg=>"Don't understand $_" +} } }

See Apocalypse 4 and Exegesis 4

 _  _ _  _  
(_|| | |(_|><
 _|   

Replies are listed 'Best First'.
Re^2: (Sort of) poll: what Perl6 features do you consider {likely,desirable} to leak into P5?
by Juerd (Abbot) on Mar 09, 2005 at 15:49 UTC

    I would definitely love to have a native given expression today. It does not mean that I believe it's likely, but certainly it's highly desirable.

    The real power is not in given/when but in the smart match operator, ~~. I see no reason why it couldn't be implemented in current Perl, as infix ~~ doesn't clash with any existing operator. Obviously, the negated version (!~) can't exist, but not/! fixes that easily, and we could use even opt to use !~~ for the time being.

    All we need is a volunteer to patch perl. :)

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      I see no reason why it couldn't be implemented in current Perl, as infix ~~ doesn't clash with any existing operator.
      There isn't a technical reason why it couldn't be implemented. I think the main reason it won't get implemented is that the people really wanting it aren't going to write the patch, and the few that do write large patches for perl5 have other priorities.

      Write a solid patch that does implement binary ~~, addressing all possible backwards compatability issues, and you'll have a decent chance of getting the operator in Perl.

      And that's true for all Perl6 features people want find its way into Perl5. Wishing for it won't get it implemented. Voting for them won't get them implemented. Discussing here how useful the features would be won't get them implemented.

      The basic rule for adding new features to perl5 has been for several years: write a patch that adds the feature. Discussing the idea on p5p first might not be a bad idea, (if only to avoid doing work for something that won't get accepted). But unless you write the patch, or find someone to write it, it's unlikely to be added.

        And that's true for all Perl6 features people want find its way into Perl5.

        Only in theory. Some syntax is incompatible and will because of that not happen. Some things are, compared to big things like currying, an object model, good threading, junctions, hyperops, and rules, quite simple to implement. Operators like // and ~~ are good examples. Of these, // is much easier to implement, and that's probably why it already has been implemented. That doesn't mean nobody will volunteer to code up ~~.

        Wishing for it won't get it implemented. Voting for them won't get them implemented. Discussing here how useful the features would be won't get them implemented.

        Very true, but I don't understand why you even took the time to type that. It's something everybody knows, and in the context of this thread could very well be interpreted as a plea to please no longer discuss Perl 5 innovation.

        Perl 5 isn't dead just yet, and we'll be using it for a long time. If someone can implement ~~, that almost gives given/when for free. I'm not saying it should be done. I'm also not at all suggesting that people who have better things to do "waste" their time on this.

        Also, wishing for features does get you into a Perl 6 mood. Every time I code Perl 5 I think "I wish I had $perl6_feature, it'd certainly make my life a bit easier this minute" every so many lines. It makes me appreciate Perl 6 and all the effort people put into its creation.

        Discussing the idea on p5p first might not be a bad idea, (if only to avoid doing work for something that won't get accepted).

        But discussing it on Perl Monks gets us whiny replies like yours. I regret that I'm even spending time to reply, but such is my nature.

        But unless you write the patch, or find someone to write it, it's unlikely to be added.

        Amen, but so what?

        Let us dream and discuss the new features. If not for Perl 5, then to celebrate Perl 6 in advance.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re^2: (Sort of) poll: what Perl6 features do you consider {likely,desirable} to leak into P5?
by brian_d_foy (Abbot) on Mar 09, 2005 at 15:01 UTC

    The Perl5 module Switch gives that to us today. There are a lot of other things that we have today, and Scott Walter's new book, Perl 6 Now, talks about a lot of them. :)

    Update: Yep, it's a source filter and it's not native, but it is there :)

    --
    brian d foy <bdfoy@cpan.org>

      Switch is hardly comparable to a native implementation.

      From the docs:
      BUGS
      There are undoubtedly serious bugs lurking somewhere in code this funky :-) Bug reports and other feedback are most welcome.

      LIMITATIONS
      Due to the heuristic nature of Switch.pm's source parsing, the presence of regexes specified with raw ?...? delimiters may cause mysterious errors. The workaround is to use m?...? instead.
      Due to the way source filters work in Perl, you can't use Switch inside an string eval.
      If your source file is longer then 1 million characters and you have a switch statement that crosses the 1 million (or 2 million, etc.) character boundary you will get mysterious errors. The workaround is to use smaller source files.

      Not the kind of things you'd like to deal with when you are coding in a hurry ...

      To use Switch; is definitly a bad idea. I just don't get it why such a wiggly thing is in the core.


      holli, /regexed monk/

        Personally, I don't like any source filters, but other people have different ideas about them. I tend to think they are just asking for trouble (and may be an example of how Perl is too flexible).

        Still, people like to play with those. I've never really longed for a switch statement, so I don't mind either way as long as it doesn't show up in my production code. :)

        --
        brian d foy <bdfoy@cpan.org>