Steve Fink writes:
: Despite all that, I don't have strong feelings about this RFC. I just
: thought it would be an interesting idea to bring to Larry's eyes.
Well, the fact is, I've been thinking about possible ways to get rid
of =~ for some time now, so I certainly don't mind brainstorming in
this direction.
: True. I can't really pin down why my intuition really likes + to be
: infix but gets confused by =~ being infix. Perhaps because it implies
: that there's something special about binding an expression to be matched
: against, and I don't see anything special about it. I like '+' because
: it's standard notation from the Real World. =~ has no real world
: equivalent, and in fact I don't know how to pronounce it in English so
: that $x =~ /a/ makes sense. "matched against" is the best I can do,
: unless it's in boolean context where "matches" works.
Yes, that's all pretty much on the mark.
: > The other thing that I think is missing from the proposal is a
: > discussion of precedence issues. For example, you did not say what
: >
: > /pat/ $x . $y ;
: >
: > would do. Is it equivalent to
: >
: > /pat/ ($x . $y) ;
: >
: > or to
: >
: > (/pat/ $x) . $y ;
: >
: > ?
:
: Good point. I'm thinking of pretty low precedence, just above '..'. So
: /pat/ $x || "abc" would be /pat/ ($x || "abc"), but /pat/ $x += 3 would
: be (/pat/ $x) += 3. Or maybe a better example is /pat/ $x, 3 is (/pat/
: $x), 3 instead of /pat/ ($x, 3). Your example would be /pat/ ($x . $y).
The problem here is that I think =~ does one thing right--it brings the
"topic" out front. Hiding the variable to be modified clear out at the
end of a big regex is not going to be a winner. It's bad enough that
the /x modifier comes at the end.
More generally, both =~ and indirect objects provide a way to put
optional arguments out in front of mandatory arguments. Perhaps this
notion can be generalized somehow. But that's a problem for -language.
Larry
