> Going back to patterns, this gives us an added bonus. It not only > explains the behavior of hypotheticals, but also of subexpression > placeholders, which are created when the pattern returns: > > $self but lexicals(0=>$self, 1=> $self.{1}, 2=> $self.{2}, etc...) > > That yields the side effect that you can say: > > sub match_digits($string //= $_) { > return / (\d+) /; > } > if match_digits("The time is 12:03") { > print $1; > } > > I think this is a very clean and simple way to get everything that > patterns were supposed to do plus a lot of added benefit for things > like: > > sub getpwuid(int $uid //= $_) { > %pwd = external("getpwuid",$uid); > return %pwd but lexicals(%pwd); > } > getpwuid($<); > print "I am $user from $dir, and I have a secret ($passwd)\n"; > > You should be able to "protect" yourself from these side effects. There > are two ways to do that: > > {getpwuid($<)} > > or > > getpwuid($<) but lexicals(); > > I would expect either one of those to work, though the second is a bit > of magic in terms of order of events.
This does bring up an interesting point. I think your solution is an interesting idea, but not really necessary. But consider this: my $date; # lots of code sub foo { #lots more code sub bar { #lots more code m/ $date := <date> /; } } This is terrible. Calling foo which calls bar mysteriously overwrites $date? "Why is $date changing?" the programmer asks. He does an exhaustive search through his code and finally says "ohhhhhh," and has to change all references to the inner $date to something like $mydate. This is obviously a problem (unless I misunderstood how hypotheticals change their surrounding scope). For a solution, let's just look how we do it in subroutines. my $date; sub foo { my $date = 'Jul 17, 1984'; # ... } Oh. Duh. Why don't we have such a mechanism for matches? m/ my $date := <date> / is ambiguous to the eyes. But I think it's necessary to have a lexical scoping mechanism for matches, as to avoid the problem I addressed above. Any ideas? Luke