in reply to Re: RFC: named pattern match tokens
in thread RFC: named pattern match tokens

Perl5 has it in a limited way

The Perl5 code you've shown is not really the same, because the names are defined outside of the pattern. The idea is, the pattern contains not only the thing to be matched, but the name to give the match.

Replies are listed 'Best First'.
Re^3: RFC: named pattern match tokens
by SpanishInquisition (Pilgrim) on Oct 05, 2004 at 16:36 UTC
    While it is true that they are not the same, it does have the benefit of not creating a hash to muck with, as hashes (as nice as they are), do not interpolate. Plus, it does not require a non-standard module to be installed :) Actually this is a really cool trick and will replace my dealings with $1 and $2 in future code, thanks hardburn.

    OT, in regard to hashes and why I don't like to use them in some places, does anybody know if Perl6 can/will do the Ruby-esque  print "hash value for key #[$key] is #[$hash{$key}]" ... basically interpolating arbitrary code (even functions) into strings. Would be cool and it definitely cuts down on verbosity of string concatenation.

      I don't like the list-context regexp matching feature, and try to always avoid it.

      One disadvantage of the () = /regex/ syntax is that it does not work for continued (/g) matching. () = /regex/g does something else. Is is usually not easy to convert a /g matching to a matching not using /g.

      I however don't understand what you say about hashes not interpolating. You certainly wouldn't want a whole hash to interpolate at once, only a hash element, which can be interpolated like "John is $john{age} years old."

      Btw, the ruby syntax for interpolating arbitary code is #{CODE}, and I think the perl6 syntax will be $(CODE) but I don't really follow p6 news so I'm not sure.

        One disadvantage of the () = /regex/ syntax is that it does not work for continued (/g) matching.

        It doesn't? Maybe I'm not understanding what you're getting at, but this works just how I'd expect:

        print "foo bar" =~ /(\w+)/, "\n"; # prints "foo" print "foo bar" =~ /(\w+)/g, "\n"; # prints "foobar"
      Actually this is a really cool trick

      Indeed. I use the return value in list form often (in fact, the code in my original post uses that technique), and it is a useful feature. There are many cases where it is much nicer than the alternatives. That is beside the point, though. The point is, hardburn showed a nifty feature that is somewhat similar, but not quite. I just wanted to explain why it was not quite the same.

      hashes (as nice as they are), do not interpolate

      Sure, you can't dump the entire hash contents as easily as you can with an array, but individual hash elements interpolate just fine:

      my %hash = (one => 1, two => 2); print "$hash{one}\n";

      And if you really want the entire hash contents, you can use the array dereference interpolation trick:

      print "@{[ %hash ]}\n";

      This trick can be used to interpolate arbitrary code, as long as the ultimate return value is an array reference. It is fairly ugly, though, and usually avoided. Here's a simple demonstration:

      print "@{ for (1 .. 2) { print qq(Hi!\n); } [ qq(Bye!\n) ]}";