Why do we say the =~ operator "binds"?

[Cody Pendant]

Not exactly a mission-critical question, but it's been puzzling me for a while.

Why do the docs say that

Binary "=~" binds a scalar expression to a pattern match.

I just don't really understand the way in which the word "bind" is being used there.

[krusty]

One reason is to verbally differentiate it from the assignment operator. Syntactically, there is already a notable difference. A common perl mistake is to state the following:

$var = /$pattern/;

which actually checks the pattern against the global special default variable $_ and sets $var to either "" or 1 (result of evaluating match). Probably not what the hapless programmer meant to say. I suppose one could read it as:

matches against $var =~ /$pattern/,
substitutes against $var =~ s/$pattern/$replacement/,
or even transliterates against (yikes, that's a mouthful) $var =~ tr/a-z/A-Z/.

but the word bind will work nicely for all three.

Another reason may be just because Larry Wall felt like it at the time. ;-)

Cheers,
Kristina

[diotalevi]

$var = /$pattern/; probably isn't a bug. I've writen that plenty of times. I'd hate for people to read that and think I didn't actually mean assignment.

[William G. Davis]

I'd hate for people to read that and think I didn't actually mean assignment.


Then don't write it that way:

foreach my $address (@email_addresses) {
    my $is_valid = $address =~ /[a-zA-Z0-0.]+\@[a-zA-Z0-0.]+/;

    if ($is_valid) {
        ....
    }
}

Seriously, if you're writing code for public consumption and think, "Gee, I hope who's ever reading this can understand it," then rewrite it so you're sure they'll be able to understand it, or comment it, or do both.

[demerphq]

As long as $var was named something like $count, or possibly $matched, or the context itself gave this information then I would say its fine. If $var was actually $str or the like I would probably say it was a bug. If it said ($var)=/$pattern/ it would almost certainly be fine regardless.

[Wassercrats]

For $var =~ /pattern/, I'd prefer "$var is associated with /pattern/" or for a substitution: "/pattern/ acts upon $var" could be used. Binds makes it sound like a more permanent or default association. Bind would be appropriate when saying "/pattern/ binds with $_."

[jdporter]

"is associated with" isn't any better than "binds" (or "is bound to").
There is no binding, there is no associating.
The expressions on the two sides of the =~ are simply arguments to a built-in function.

It is far more accurate to talk about "applying" the pattern to the string.
Or, for Jah's sake, why not simply "the string is tested against the pattern"?
"=~ is the pattern-applying operator."

[Zaxo]

It just means that the preceeding string or variable will be the lhs of the following m//, s///, or tr/// operator. I would also be interested to know why that's necessary, now that you mention it.

[demerphq]

Essentially regexen are two argument (or three argument or hypothetically four) operators which as far as operators go is pretty weird (note the only common operator like this is the ? : ternary operator. Since the nature of the operator itself has room for, 1, (or two or three depending on how you look at it) additional arguments there needs to be a way to invole the fourth.

Sorry. to convert all that gobbleygook, look at this:

$foo    =~ s/bar     /baz              /x

EXPR(1) =~ s/REGEX(2)/STRING_OR_EXPR(3)/MODIFIERS(4)

had the regex operators been expressed as function calls this might have worked as an option set, but notice that in some cases various arguments can be omitted. So if EXPR(1) is omitted $_ is used, in an s/// if REGEX(2) is omitted it uses the last m// pattern on the subject (EXPR(1)), and the modifiers can be omitted. So if this had been positional arguments it would have had a pretty strange argument signature. Try to come up with a reasonable way to pass the arguments into a function based s/// implementation with same behaviour of default operation on $_, and etc. Its not going to be nice, with many common calls using undef in their parameter list. Or alternatively hopelessly verbose like the dotNet regex implementation.

So in short regex like operators need the binding part because its an optional part (at the front no less) of what is essentially a quaternary operator.

Also as a last thought....

  my $count=(my $copy=$original)=~s/-(Foo|Bar)-/$1/g;

:-)

[bart]

It just means that the preceeding string or variable will be the lhs of the following m//, s///, or tr/// operator.

No it doesn't.

The string or variable is both in- and (optionally) output of the operation. That puts it in a rather special relationship with regards to the operation, and the language designers chose to name this connection "binding". It's stronger than just input or output.

[duff]

There's all sorts of state involved in pattern matching. Some of it is held by the pattern, some of it by the string upon which it acts. For instance, take a look at perldoc -f study. So, =~ binds these two things together.

[halley]

The term "binding" is often used when talking about the process of unification. A set of entities are assigned values at once, but only if values for each entity can be found. The destination (left-hand side) entities cannot be assigned if an insufficient set of source (right-hand side) values are found.

If you understand databases, you can think of it like a transaction: if any of the portions of the database insertion fails, the whole transaction is rolled back as if it was never attempted.

You may want to look at my CPAN module Data::Binder which provides a similar, simplistic method of maintaining a set of entities, which can be bound against each other.

[sfink]

Standard terminology for function calling in languages that have named parameters (i.e., almost all of them). If you have a function f(int $a, string $b) and you call it with f(10,"gzarp!"), then it is said that the parameter $a is bound to the argument 10, and the parameter $b is bound to the argument "gzarp!". (Or vice versa -- "gzarp!" is bound to $b, but binding is reflexive so it doesn't matter all that much. Though you could have multiple arguments bound to the same parameter in a language like Perl6.)

Regex matching is really an operator, not a function call, but the terminology is the same. Well, except you'd probably call them operands instead of parameters.

Or at least, this is the way I think about it. The terminology always made sense to me because for a long time when I started writing perl, I just used /.../ and therefore left the match string bound to the default $_. (I didn't even know there was a $_ for a while; it just all somehow magically worked out when I did a while(<>) loop.) At some point, I had a string in my own $variable that I wanted to match, and "binding" seemed as good a word as any to describe how to set the string that I was applying the match to.