Request for regexp literals and matches operator

[anders-sandholm]

Feature request for JS-like regexp literals from Mike (harmic@gmail.com) requested on misc@dartlang.org:

I really like the way I can say:

if ($date =~ /^\d+-\d+-\d+$/) { ....

to give a trivial example. The dart alternative of:

var dateRe = const RegExp(@­"^\d+-\d+-\d+$");
if (dateRe.hasMatch(date)) { ...

doesn't roll off the tongue in the same way.

So, I would like to propose two improvements.

1. The introduction of a regexp literal, /{regex}/[{flags}], which
   would result in construction of a const RegExp instance, so one would
   be able to say:

var dateRe = /^\d+-\d+-\d+$/;

This is not without precedent since Javascript already has such a
construct (as does Perl of course, but in a much messier way). The
flags could be 'i' for case insensitive, 'm' for multiline. It might
also be good to allow for 'x' similar to in perl, so that regex
literals can have embedded whitespace and comments - without which
some REs can be impossible to decipher.

1. The introduction of a 'matches' operator, =~, such that the
   expression

o1 =~ o2

is equivalent to:

o2.firstMatch(o1)

In addition a 'does not match' operator !~, equivalent to !
o2.hasMatch(o1)

These two combined would allow my original example to be written in
dart as:

if (date =~ /^\d+-\d+-\d+$/) { ....

This allows for the simple case of checking if something matches, but
also because =~ is equivalent to firstMatch, it will either return a
Match object or null, so one can say:

if (dateMatch = (date =~ /^(\d+)-(\d+)-(\d+)$/)) { ....

In the case of a succesful match, dateMatch will contain the result of
the match.

[rakudrama]

I have always thought that regexps as switch-statement case-labels would be interesting.
/bin/sh has a rudimentary case matching (based on filename 'glob' patterns) and this is useful for parsing command line arguments. A full blown regexp would be similarly useful for parsing ad-hoc data. The difficulty is figuring out how to extract the match groups and bind them to a variable for further processing.

[gbracha]

Set owner to @gbracha.
Added Accepted label.

[DartBot]

This comment was originally written by @seaneagan

---

If a matches operator ( =~ ) is added, it should probably be overridable as with most other operators. The String implementation would look something like:

bool operator =~ (Regexp r) => r.hasMatch(this);

or maybe even allow arbitrary Patterns:

bool operator =~ (Pattern p) => this.contains(p, 0);

[DartBot]

This comment was originally written by harmic...@gmail.com

---

To explain the motivation a bit further:

1. Many languages provide regexes purely via an object oriented API -
   eg. Javascript, Java, Python. The problem is they all have slightly
   different interfaces, eg:

JS - new RegExp(pattern).test(string)
Java - Pattern.matches(pattern, string)
Python - re.match(pattern, string)

It is actually a bit of a nightmare to remember wether one should use
test, match, matches, hasMatch, etc etc.

The =~ operator is much easier to memorize, IMHO.

Of course it does not replace the OO API, just provides some nice
syntactic sugar.

1. The examples given above for JS, Java and Python are actually all
   bad examples if you are repeatedly matching a regex. It is relatively
   expensive to compile a regex, so you want to do it once only if
   possible. In fact the examples I was giving were shorthand - for
   example in Java you would probably really compile the pattern as a
   static variable and use it throughout.

But, the reality is that a lot of people writing programs in scripting
languages are not experienced programmers. Many would not realize that
the above constructs are not efficient. Thats why a regex literal that
is automatically resolved at compile time is a good idea.

1. The use of '/' as delimeters to the regex literal, instead of
   coding the regex inside a string, means you do not have to worry about
   string escaping interfering with the embedded backslashes in the
   pattern. Ie. no need for @­"pattern". I have not seen the use of an @­
   to indicate backslashes should not be interpreted inside a string
   literal before - I suspect it would not be familiar to many newcomers
   and thus might lead to mistakes when people forget to add it.

BTW, so far no one has commented on the suggestion that =~ should be
equivalent to firstMatch( ) instead of hasMatch( ). The rationale for
that is so that one can access the result of the match - it is very
common to want to check if a pattern is matched and then, if so, to be
able to access the grouped expressions within the match. But it also
means that =~ does not return a boolean, it would return either a
match object or null.

My reading of the language spec is that this should not work, since
10.4.1 says that any object other than the true object should convert
to false. But when I tried it out on the dartboard it does work:

main() {
  RegExp re = const RegExp(@­"^(\d+)-\d+-\d+$");

  var date="2011-01-01";
  var match;

  if (match = re.firstMatch(date)) {
    print("Matches - year is "+match.group(1));
  }

}

produces: "Matches - year is 2011", and no warnings.

I guess you can get the same effect legally using:

     if ((match = re.firstMatch(date)) != null) {

although that's not so nice to read and kind of defeats the purpose of a simple =~ operator.
 

[anders-sandholm]

Added apr30-triage label.

[anders-sandholm]

Removed apr30-triage label.

[anders-sandholm]

Added triage1 label.

[anders-sandholm]

Removed triage1 label.
Added WontFix label.

[gbracha]

We decided we will be happier keeping this at the library level (as in Java or Python). We keep the language small that way, which is a win in many ways.

[DartBot]

This comment was originally written by source.s...@gmail.com

---

You are being lazy. :)

Just make the language construct /^fo"o// merely translate to new RegExp(r"^foo"o/"); where RegExp is not any specific implementation. Merely have the language interprets it in context. Essentially the syntax would be pure syntactic sugar and nothing more.

Surely such a simple translation from a string surrounded in /'s to a raw string isn't anything to worry about when thinking about "increasing the size of the language." It has such widespread use in other languages that there's very little reason not to have it.

Also, the =~ should be in the language regardless of if we have the /foo/ syntax or not.

[DartBot]

This comment was originally written by beatgamm...@gmail.com

---

Just another plug for the regex literal. I use them every day in JS, and I find it really convenient to do:

    if (/^fo+/.test("foobar"))

Instead of the more verbose:

    var re = new RegExp("^fo+");
    if (re.test("foobar"))

I understand the desire to keep things small, but RegExp is not something many users will care to replace with another implementation. Moving this to a library eliminates the possibility for nice syntax sugar, which I think is a fail in many ways.

I am still mad that Go decided to not have the RegExp literal, and I think it's a step backward to ignore functionality that worked in JS. I was under the impression that Dart was an attempt to keep the good parts of JS (and other languages), not an attempt to make a minimal feature-set language.

Please reconsider this decision.

[justinfagnani]

Issue #9983 has been merged into this issue.

[gbracha]

Issue #10519 has been merged into this issue.

[gbracha]

Issue #21697 has been merged into this issue.