If "=~ is the pattern applying operator", then code like if( /foo/ ) would never apply the regex. The two sides of =~ are *not* passed to some built-in function as arguments. The right-hand side is what is run and the left-hand side is the argument if it is present. An "unbound" regex still gets applied. Matching happens even without =~.

The =~ (mostly) is *not* what makes pattern matching happen. The regex is what makes pattern matching happen and the =~ (if present) binds a string to the regex to tell it what to match against (other than the default).

Now, if you have =~ with something that isn't a regex to its right, then you have rather bizarre code and are at the mercy of dubious "do what I mean" guessing. If Perl happens to currently insert a regex constructor for you, my main reaction is that I know I have no code that relies on such.

So the reason we say 'bind' is because one side is the code to run. Like '(' is used to bind arguments to a function -- '(' is not "the function invoking operator", despite that description being somewhat appropriate.

There's two issues, happening at two levels of abstraction. At a low (more concrete) level, the two sides of =~ are two arguments of a built-in function. (Yes, at an even lower level, there is no actual such function.) The absence of =~ and its LHS simply indicate to use a default argument there. What to call the =~ operator is an issue at a higher (more abstract) level. It doesn't have to correspond to what's really happening inside the interpreter, or even what we think is happening; but it should accurate reflect how we think of the operator conceptually. And by this standard, "bind" (or "associate") is a very poor choice of terms. Even given your analogy that a regex is kind of function, arguments do not get "bound" to functions. (Arguments get "bound" to parameters, but even that terminology is rarely seen in the Perl community.) I happen to think that "pattern applying" works, but I'll happily concede that there may be something better. "Regex argument passing operator" sounds like it may be accurate, but obviously is unacceptably long.