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


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

Of these, // is much easier to implement, and that's probably why it already has been implemented.
No. The main reason it was implemented is because people have wanted this for at least a decade. And wanted it badly. There have been some very heated arguments about this operator (and its name, anyone remember the ||| and ?? suggestions?) in the past.
in the context of this thread could very well be interpreted as a plea to please no longer discuss Perl 5 innovation.
Then you have missed the meaning of what I wanted to indicate. My point is that, compared with the past, development of Perl5 seems to be done by only a few people. I'd welcome it if more people worked on Perl5!
But discussing it on Perl Monks gets us whiny replies like yours.
The only thing that gets me 'whiny' is when I see people suggesting things that should be implemented - but without doing the legwork themselves. I read your see no reason why it couldn't be implemented in current Perl as being such a suggestion.

My point is that we can all wish for Perl6 features to be implemented in Perl5, but that "not breaking backwards compatability" isn't the only reason they won't find their way into Perl5. Someone has to actually do the work.

But unless you write the patch, or find someone to write it, it's unlikely to be added.
Amen, but so what?
Well, you saw no reason why it couldn't be implemented in current Perl - but I did. And that's the reason.
  • Comment on Re^5: (Sort of) poll: what Perl6 features do you consider {likely,desirable} to leak into P5?

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

    The main reason it was implemented is because people have wanted this for at least a decade. And wanted it badly. There have been some very heated arguments about this operator (and its name, anyone remember the ||| and ?? suggestions?) in the past.

    If the idea behind the feature that ~~ represents existed this long, it would have too. It is new, though. However, it gives us given/when and THAT has also been wanted for a very long time. Just see Google Groups and our own Perl Monks for proof. In fact, I think a switch statement has been asked for/about much more often than defined-or.

    I read your "see no reason why it couldn't be implemented in current Perl" as being such a suggestion.

    I was evaluating the technical possibility, not implying that it SHOULD be done.

    Well, you saw no reason why it couldn't be implemented in current Perl - but I did. And that's the reason.

    It could, but it probably won't.

    Or, well, I asked xmath if it would be easy to implement ~~ so that it called a perl side sub. This would enable me to do the comparisons themselves in Perl, probably reusing some logic from Switch.pm. (Consider File::Glob.) xmath answered my question by saying it wouldn't be a great deal of work, and my gut says he's already started working on it even though I haven't asked for the actual implementation yet :)

    And he brought up an improbable but existing clash: foo~~bar is now foo(~~bar). But I think we should just strongly state that scalar should be written as scalar instead of ~~ ;) (Those who really want to use ~~ for the first argument of a function, can use + or parens to disambiguate.)

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