http://www.tiobe.com/tpci.htm

We've risen to number 29!

Walter wrote:
> http://www.tiobe.com/tpci.htm
> 
> We've risen to number 29!

Congratulations, Walter!!!!!!!!!!

D was above some veritable and important languages, to boot!
And D won't stop here!

I'm really surprised that D's above Ruby.

All we need now is to use that reserved $ for built-in regex, and D will be on its way to top place. :-)

(And the DLL stuff, and the Exception Hierarchy, and ...  but I'm looking to the non-too-distant future with optimism)

"Walter" <newshound@digitalmars.com> wrote in message news:cuo83m$1mjn$1@digitaldaemon.com...
> http://www.tiobe.com/tpci.htm
>
> We've risen to number 29!
>
> 

> All we need now is to use that reserved $ for built-in regex, and D will be on its way to top place. :-)

I'm curious what you having in mind for built-in regex. Do you mean that basically constructing a RegExp instance will be implicit? What are the advantages of making it built-in?

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:cuol7o$235h$1@digitaldaemon.com...
>> All we need now is to use that reserved $ for built-in regex, and D will be on its way to top place. :-)
>
> I'm curious what you having in mind for built-in regex. Do you mean that basically constructing a RegExp instance will be implicit? What are the advantages of making it built-in?

FOA, let me stipulate that this is _not_ something I'm going to be dogmatic, or attempt to be authoritative/right, about, because it's absence is not in any sense a flaw. Given that:

I'm doing a _lot_ of scripting at the moment, much of it in Ruby, and some of it in Python. The difference in utility between the two languages is generally small - Ruby's syntax is a bit neater/easier/more succinct, whereas Python's libs are more mature / extensive.

However, the difference when it comes to using regular expressions is huge. Ruby's regex syntax is very much like Perl's, as in

    if line =~ /unquoted-regex-pattern-here/
        gr1 = $1
        gr2 = $2
        etc ...

With Python, one has to use a class interface, e.g.

    re_match_X = re.compile(r'unquoted-regex-pattern-here')

    m = re_match_X(line)
    if m:
        gr1 = m.group(1)
        gr2 = m.group(2)
        etc ...

Note the significant disadvantage with Python, over and above the verbosity, is the fact that one cannot do the following:


    m = re_match_X(line)
    if m:
        gr1 = m.group(1)
        gr2 = m.group(2)
        etc ...
    elif (m = re_match_Y(line)):
        gr1 = m.group(1)
        gr2 = m.group(2)
        etc ...

leading to really horrible conditional nesting - Yeuch! - whereas one can do it in Ruby:


    if line =~ /unquoted-regex-pattern-here/
        gr1 = $1
        gr2 = $2
        etc ...
    elsif line =~ /different-unquoted-regex-pattern-here/
        gr1 = $1
        gr2 = $2
        etc ...

which keeps everything beautifully nice and neat.

Note that in Ruby one can also use the RegEx class(es) explicitly, but I've never bothered, since the built-in stuff is so fabulously convenient. This and Ruby's ridiculously easy extension mechanism (c/w Python) are the two reasons I favour Ruby over everything - Python, Perl, C/C++, D - whenever I can. (With no disrespect intended, on the two occasions I've tried to use D's regex I've found it pales in comparison, and have prefered to write the program in Ruby.)

Given my experience with Python and Ruby (and D), I personally strongly believe that built-in regex for D would be very popular. The downside is that it's coupling syntax with libraries. D does some of that already, but it's not a practice one should encourage in general. I believe that it'd be well worth it in this case, but I accept that others may not think so.

Naturally I'd see this as a D 1.1 feature. I imagine it'd complicate things way too much now.

Cheers


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

"But if less is more, think how much more more will be!" -- Dr Frazier Crane

-------------------------------------------------------------------------------

For the love of Bob -- no!

There's already enough built-in baggage with AAs, .sort, and their consorts

- Kris


In article <cuonb2$24tf$1@digitaldaemon.com>, Matthew says...
>
>
>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:cuol7o$235h$1@digitaldaemon.com...
>>> All we need now is to use that reserved $ for built-in regex, and D will be on its way to top place. :-)
>>
>> I'm curious what you having in mind for built-in regex. Do you mean that basically constructing a RegExp instance will be implicit? What are the advantages of making it built-in?
>
>FOA, let me stipulate that this is _not_ something I'm going to be dogmatic, or attempt to be authoritative/right, about, because it's absence is not in any sense a flaw. Given that:
>
>I'm doing a _lot_ of scripting at the moment, much of it in Ruby, and some of it in Python. The difference in utility between the two languages is generally small - Ruby's syntax is a bit neater/easier/more succinct, whereas Python's libs are more mature / extensive.
>
>However, the difference when it comes to using regular expressions is huge. Ruby's regex syntax is very much like Perl's, as in
>
>    if line =~ /unquoted-regex-pattern-here/
>        gr1 = $1
>        gr2 = $2
>        etc ...
>
>With Python, one has to use a class interface, e.g.
>
>    re_match_X = re.compile(r'unquoted-regex-pattern-here')
>
>    m = re_match_X(line)
>    if m:
>        gr1 = m.group(1)
>        gr2 = m.group(2)
>        etc ...
>
>Note the significant disadvantage with Python, over and above the verbosity, is the fact that one cannot do the following:
>
>
>    m = re_match_X(line)
>    if m:
>        gr1 = m.group(1)
>        gr2 = m.group(2)
>        etc ...
>    elif (m = re_match_Y(line)):
>        gr1 = m.group(1)
>        gr2 = m.group(2)
>        etc ...
>
>leading to really horrible conditional nesting - Yeuch! - whereas one can do it in Ruby:
>
>
>    if line =~ /unquoted-regex-pattern-here/
>        gr1 = $1
>        gr2 = $2
>        etc ...
>    elsif line =~ /different-unquoted-regex-pattern-here/
>        gr1 = $1
>        gr2 = $2
>        etc ...
>
>which keeps everything beautifully nice and neat.
>
>Note that in Ruby one can also use the RegEx class(es) explicitly, but I've never bothered, since the built-in stuff is so fabulously convenient. This and Ruby's ridiculously easy extension mechanism (c/w Python) are the two reasons I favour Ruby over everything - Python, Perl, C/C++, D - whenever I can. (With no disrespect intended, on the two occasions I've tried to use D's regex I've found it pales in comparison, and have prefered to write the program in Ruby.)
>
>Given my experience with Python and Ruby (and D), I personally strongly believe that built-in regex for D would be very popular. The downside is that it's coupling syntax with libraries. D does some of that already, but it's not a practice one should encourage in general. I believe that it'd be well worth it in this case, but I accept that others may not think so.
>
>Naturally I'd see this as a D 1.1 feature. I imagine it'd complicate things way too much now.
>
>Cheers
>
>
>-- 
>Matthew Wilson
>
>Author: "Imperfect C++", Addison-Wesley, 2004
>    (http://www.imperfectcplusplus.com)
>Contributing editor, C/C++ Users Journal
>    (http://www.synesis.com.au/articles.html#columns)
>STLSoft moderator
>    (http://www.stlsoft.org)
>
>"But if less is more, think how much more more will be!" -- Dr Frazier Crane
>
>-------------------------------------------------------------------------------
> 
>
>

I understand your POV: one man's convenient construct is another's baggage.

I think I _may_, if I ever have any spare time, write a D preprocessor, so I can have it without upsetting you. ;)

"Kris" <Kris_member@pathlink.com> wrote in message news:cuoots$267h$1@digitaldaemon.com...
> For the love of Bob -- no!
>
> There's already enough built-in baggage with AAs, .sort, and their consorts
>
> - Kris
>
>
> In article <cuonb2$24tf$1@digitaldaemon.com>, Matthew says...
>>
>>
>>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:cuol7o$235h$1@digitaldaemon.com...
>>>> All we need now is to use that reserved $ for built-in regex, and D will be on its way to top place. :-)
>>>
>>> I'm curious what you having in mind for built-in regex. Do you mean that basically constructing a RegExp instance will be implicit? What are the advantages of making it built-in?
>>
>>FOA, let me stipulate that this is _not_ something I'm going to be dogmatic, or attempt to be authoritative/right, about, because it's absence is not in any sense a flaw. Given that:
>>
>>I'm doing a _lot_ of scripting at the moment, much of it in Ruby, and
>>some of it in Python. The difference in utility between the two
>>languages is generally small - Ruby's syntax is a bit
>>neater/easier/more
>>succinct, whereas Python's libs are more mature / extensive.
>>
>>However, the difference when it comes to using regular expressions is huge. Ruby's regex syntax is very much like Perl's, as in
>>
>>    if line =~ /unquoted-regex-pattern-here/
>>        gr1 = $1
>>        gr2 = $2
>>        etc ...
>>
>>With Python, one has to use a class interface, e.g.
>>
>>    re_match_X = re.compile(r'unquoted-regex-pattern-here')
>>
>>    m = re_match_X(line)
>>    if m:
>>        gr1 = m.group(1)
>>        gr2 = m.group(2)
>>        etc ...
>>
>>Note the significant disadvantage with Python, over and above the verbosity, is the fact that one cannot do the following:
>>
>>
>>    m = re_match_X(line)
>>    if m:
>>        gr1 = m.group(1)
>>        gr2 = m.group(2)
>>        etc ...
>>    elif (m = re_match_Y(line)):
>>        gr1 = m.group(1)
>>        gr2 = m.group(2)
>>        etc ...
>>
>>leading to really horrible conditional nesting - Yeuch! - whereas one can do it in Ruby:
>>
>>
>>    if line =~ /unquoted-regex-pattern-here/
>>        gr1 = $1
>>        gr2 = $2
>>        etc ...
>>    elsif line =~ /different-unquoted-regex-pattern-here/
>>        gr1 = $1
>>        gr2 = $2
>>        etc ...
>>
>>which keeps everything beautifully nice and neat.
>>
>>Note that in Ruby one can also use the RegEx class(es) explicitly, but I've never bothered, since the built-in stuff is so fabulously convenient. This and Ruby's ridiculously easy extension mechanism (c/w Python) are the two reasons I favour Ruby over everything - Python, Perl, C/C++, D - whenever I can. (With no disrespect intended, on the two occasions I've tried to use D's regex I've found it pales in comparison, and have prefered to write the program in Ruby.)
>>
>>Given my experience with Python and Ruby (and D), I personally
>>strongly
>>believe that built-in regex for D would be very popular. The downside
>>is
>>that it's coupling syntax with libraries. D does some of that already,
>>but it's not a practice one should encourage in general. I believe
>>that
>>it'd be well worth it in this case, but I accept that others may not
>>think so.
>>
>>Naturally I'd see this as a D 1.1 feature. I imagine it'd complicate things way too much now.
>>
>>Cheers
>>
>>
>>-- 
>>Matthew Wilson
>>
>>Author: "Imperfect C++", Addison-Wesley, 2004
>>    (http://www.imperfectcplusplus.com)
>>Contributing editor, C/C++ Users Journal
>>    (http://www.synesis.com.au/articles.html#columns)
>>STLSoft moderator
>>    (http://www.stlsoft.org)
>>
>>"But if less is more, think how much more more will be!" -- Dr Frazier Crane
>>
>>-------------------------------------------------------------------------------
>>
>>
>>
>
> 

For what it's worth, I work a lot with PHP and I've worked a lot with C#, Perl, Assembly, and several other languages as well.  When I found that Perl could do this, I thought at first it would be horribly slow, and parsing it would be painful.

But, much to the contrary, the parsing is fairly straight-forward (like strings) and the syntax is fairly clean.  The only part I've never really liked about it is ~=, but you can't have everything.

Anyway, as I said above I've worked largely in PHP for the past while, and so I just use its functions "preg_match", "preg_replace", and so forth.  There's no compilation step (although I can see that being very useful for any regular expressions I might use in a loop... which, theoretically, could be optimized out by a compiler.)

So, while I agree that using it outside quotes is very preferrable, especially to reduce escaping (although we have wysiwyg strings in D, no?) I think having a proper interface to it would suffice as well.

That said, theoretically you could simply do this with D:

new RegExp(`[a-zA-Z]{32}-([abc])(\d+)`, "").test(line)

Which is a lot uglier than this:

line =~ /[a-zA-Z]{32}-([abc])(\d+)/

But at least it can be done in one line without having to create (and destruct) a dummy object for it.

As for matches specifically, you're right... it would be tricky.  You could still theoretically do this:

char[][] m;

if (m = new RegExp(`[a-zA-Z]{32}-([abc])(\d+)`, "").match(line) && m.length != 0)
{
    gr1 = m[1];
    gr2 = m[2];
}

Here I would personally prefer either built in syntax, or a syntax like PHP uses, which is roughly this:

int preg_match(in char[] regexp, in char[] string, out char[][] matches, in int flags = 0)

Where the function returns one if there was a match and zero if there was none.  There's also preg_match_all, which looks similar but returns the number of matches and puts them into a char[][][].  This makes it possible to use your syntax *nearly* but only with functions.

While the subject is being discussed: personally, I prefer Perl-compatible regular expressions.  While the regular expressions used in D are nice, they don't (afaik, mind you) have assertions, look behind, and other nice things.  I'd be interested to know if they are faster or slower, though...

-[Unknown]


> FOA, let me stipulate that this is _not_ something I'm going to be dogmatic, or attempt to be authoritative/right, about, because it's absence is not in any sense a flaw. Given that:
> 
> I'm doing a _lot_ of scripting at the moment, much of it in Ruby, and some of it in Python. The difference in utility between the two languages is generally small - Ruby's syntax is a bit neater/easier/more succinct, whereas Python's libs are more mature / extensive.
> 
> However, the difference when it comes to using regular expressions is huge. Ruby's regex syntax is very much like Perl's, as in
> 
>     if line =~ /unquoted-regex-pattern-here/
>         gr1 = $1
>         gr2 = $2
>         etc ...
> 
> With Python, one has to use a class interface, e.g.
> 
>     re_match_X = re.compile(r'unquoted-regex-pattern-here')
> 
>     m = re_match_X(line)
>     if m:
>         gr1 = m.group(1)
>         gr2 = m.group(2)
>         etc ...
> 
> Note the significant disadvantage with Python, over and above the verbosity, is the fact that one cannot do the following:
> 
> 
>     m = re_match_X(line)
>     if m:
>         gr1 = m.group(1)
>         gr2 = m.group(2)
>         etc ...
>     elif (m = re_match_Y(line)):
>         gr1 = m.group(1)
>         gr2 = m.group(2)
>         etc ...
> 
> leading to really horrible conditional nesting - Yeuch! - whereas one can do it in Ruby:
> 
> 
>     if line =~ /unquoted-regex-pattern-here/
>         gr1 = $1
>         gr2 = $2
>         etc ...
>     elsif line =~ /different-unquoted-regex-pattern-here/
>         gr1 = $1
>         gr2 = $2
>         etc ...
> 
> which keeps everything beautifully nice and neat.
> 
> Note that in Ruby one can also use the RegEx class(es) explicitly, but I've never bothered, since the built-in stuff is so fabulously convenient. This and Ruby's ridiculously easy extension mechanism (c/w Python) are the two reasons I favour Ruby over everything - Python, Perl, C/C++, D - whenever I can. (With no disrespect intended, on the two occasions I've tried to use D's regex I've found it pales in comparison, and have prefered to write the program in Ruby.)
> 
> Given my experience with Python and Ruby (and D), I personally strongly believe that built-in regex for D would be very popular. The downside is that it's coupling syntax with libraries. D does some of that already, but it's not a practice one should encourage in general. I believe that it'd be well worth it in this case, but I accept that others may not think so.
> 
> Naturally I'd see this as a D 1.1 feature. I imagine it'd complicate things way too much now.
> 
> Cheers
> 
> 

:-)

There are ways to make the syntax much more convenient, yet still be implemented externally ... but perhaps not to the extent you're thinking.

One thing to consider in this realm is the char/wchar/dchar implications ~ I currently have a templated version of RegExp.

- Kris


In article <cuop6d$26fi$1@digitaldaemon.com>, Matthew says...
>
>I understand your POV: one man's convenient construct is another's baggage.
>
>I think I _may_, if I ever have any spare time, write a D preprocessor, so I can have it without upsetting you. ;)
>
>"Kris" <Kris_member@pathlink.com> wrote in message news:cuoots$267h$1@digitaldaemon.com...
>> For the love of Bob -- no!
>>
>> There's already enough built-in baggage with AAs, .sort, and their consorts
>>
>> - Kris
>>
>>
>> In article <cuonb2$24tf$1@digitaldaemon.com>, Matthew says...
>>>
>>>
>>>"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:cuol7o$235h$1@digitaldaemon.com...
>>>>> All we need now is to use that reserved $ for built-in regex, and D will be on its way to top place. :-)
>>>>
>>>> I'm curious what you having in mind for built-in regex. Do you mean that basically constructing a RegExp instance will be implicit? What are the advantages of making it built-in?
>>>
>>>FOA, let me stipulate that this is _not_ something I'm going to be dogmatic, or attempt to be authoritative/right, about, because it's absence is not in any sense a flaw. Given that:
>>>
>>>I'm doing a _lot_ of scripting at the moment, much of it in Ruby, and
>>>some of it in Python. The difference in utility between the two
>>>languages is generally small - Ruby's syntax is a bit
>>>neater/easier/more
>>>succinct, whereas Python's libs are more mature / extensive.
>>>
>>>However, the difference when it comes to using regular expressions is huge. Ruby's regex syntax is very much like Perl's, as in
>>>
>>>    if line =~ /unquoted-regex-pattern-here/
>>>        gr1 = $1
>>>        gr2 = $2
>>>        etc ...
>>>
>>>With Python, one has to use a class interface, e.g.
>>>
>>>    re_match_X = re.compile(r'unquoted-regex-pattern-here')
>>>
>>>    m = re_match_X(line)
>>>    if m:
>>>        gr1 = m.group(1)
>>>        gr2 = m.group(2)
>>>        etc ...
>>>
>>>Note the significant disadvantage with Python, over and above the verbosity, is the fact that one cannot do the following:
>>>
>>>
>>>    m = re_match_X(line)
>>>    if m:
>>>        gr1 = m.group(1)
>>>        gr2 = m.group(2)
>>>        etc ...
>>>    elif (m = re_match_Y(line)):
>>>        gr1 = m.group(1)
>>>        gr2 = m.group(2)
>>>        etc ...
>>>
>>>leading to really horrible conditional nesting - Yeuch! - whereas one can do it in Ruby:
>>>
>>>
>>>    if line =~ /unquoted-regex-pattern-here/
>>>        gr1 = $1
>>>        gr2 = $2
>>>        etc ...
>>>    elsif line =~ /different-unquoted-regex-pattern-here/
>>>        gr1 = $1
>>>        gr2 = $2
>>>        etc ...
>>>
>>>which keeps everything beautifully nice and neat.
>>>
>>>Note that in Ruby one can also use the RegEx class(es) explicitly, but I've never bothered, since the built-in stuff is so fabulously convenient. This and Ruby's ridiculously easy extension mechanism (c/w Python) are the two reasons I favour Ruby over everything - Python, Perl, C/C++, D - whenever I can. (With no disrespect intended, on the two occasions I've tried to use D's regex I've found it pales in comparison, and have prefered to write the program in Ruby.)
>>>
>>>Given my experience with Python and Ruby (and D), I personally
>>>strongly
>>>believe that built-in regex for D would be very popular. The downside
>>>is
>>>that it's coupling syntax with libraries. D does some of that already,
>>>but it's not a practice one should encourage in general. I believe
>>>that
>>>it'd be well worth it in this case, but I accept that others may not
>>>think so.
>>>
>>>Naturally I'd see this as a D 1.1 feature. I imagine it'd complicate things way too much now.
>>>
>>>Cheers
>>>
>>>
>>>-- 
>>>Matthew Wilson
>>>
>>>Author: "Imperfect C++", Addison-Wesley, 2004
>>>    (http://www.imperfectcplusplus.com)
>>>Contributing editor, C/C++ Users Journal
>>>    (http://www.synesis.com.au/articles.html#columns)
>>>STLSoft moderator
>>>    (http://www.stlsoft.org)
>>>
>>>"But if less is more, think how much more more will be!" -- Dr Frazier Crane
>>>
>>>-------------------------------------------------------------------------------
>>>
>>>
>>>
>>
>> 
>
>

It seems to me that a large amount of the ugliness below is caused by using an object where none is required (i.e. we are not storing any state)

Can't we can have both:
 - an object storing regexp state allowing several calls.
 - stand alone functions that return results, eg.

foreach(char[] match; RegExp.match(`[a-zA-Z]{32}-([abc])(\d+)`,line)) {
  //process match here
}

Internally either one can be a wrapper around the other (whichever makes sense).

Regan

On Sun, 13 Feb 2005 16:24:30 -0800, Unknown W. Brackets <unknown@simplemachines.org> wrote:
> For what it's worth, I work a lot with PHP and I've worked a lot with C#, Perl, Assembly, and several other languages as well.  When I found that Perl could do this, I thought at first it would be horribly slow, and parsing it would be painful.
>
> But, much to the contrary, the parsing is fairly straight-forward (like strings) and the syntax is fairly clean.  The only part I've never really liked about it is ~=, but you can't have everything.
>
> Anyway, as I said above I've worked largely in PHP for the past while, and so I just use its functions "preg_match", "preg_replace", and so forth.  There's no compilation step (although I can see that being very useful for any regular expressions I might use in a loop... which, theoretically, could be optimized out by a compiler.)
>
> So, while I agree that using it outside quotes is very preferrable, especially to reduce escaping (although we have wysiwyg strings in D, no?) I think having a proper interface to it would suffice as well.
>
> That said, theoretically you could simply do this with D:
>
> new RegExp(`[a-zA-Z]{32}-([abc])(\d+)`, "").test(line)
>
> Which is a lot uglier than this:
>
> line =~ /[a-zA-Z]{32}-([abc])(\d+)/
>
> But at least it can be done in one line without having to create (and destruct) a dummy object for it.
>
> As for matches specifically, you're right... it would be tricky.  You could still theoretically do this:
>
> char[][] m;
>
> if (m = new RegExp(`[a-zA-Z]{32}-([abc])(\d+)`, "").match(line) && m.length != 0)
> {
>      gr1 = m[1];
>      gr2 = m[2];
> }
>
> Here I would personally prefer either built in syntax, or a syntax like PHP uses, which is roughly this:
>
> int preg_match(in char[] regexp, in char[] string, out char[][] matches, in int flags = 0)
>
> Where the function returns one if there was a match and zero if there was none.  There's also preg_match_all, which looks similar but returns the number of matches and puts them into a char[][][].  This makes it possible to use your syntax *nearly* but only with functions.
>
> While the subject is being discussed: personally, I prefer Perl-compatible regular expressions.  While the regular expressions used in D are nice, they don't (afaik, mind you) have assertions, look behind, and other nice things.  I'd be interested to know if they are faster or slower, though...
>
> -[Unknown]
>
>
>> FOA, let me stipulate that this is _not_ something I'm going to be dogmatic, or attempt to be authoritative/right, about, because it's absence is not in any sense a flaw. Given that:
>>  I'm doing a _lot_ of scripting at the moment, much of it in Ruby, and some of it in Python. The difference in utility between the two languages is generally small - Ruby's syntax is a bit neater/easier/more succinct, whereas Python's libs are more mature / extensive.
>>  However, the difference when it comes to using regular expressions is huge. Ruby's regex syntax is very much like Perl's, as in
>>      if line =~ /unquoted-regex-pattern-here/
>>         gr1 = $1
>>         gr2 = $2
>>         etc ...
>>  With Python, one has to use a class interface, e.g.
>>      re_match_X = re.compile(r'unquoted-regex-pattern-here')
>>      m = re_match_X(line)
>>     if m:
>>         gr1 = m.group(1)
>>         gr2 = m.group(2)
>>         etc ...
>>  Note the significant disadvantage with Python, over and above the verbosity, is the fact that one cannot do the following:
>>       m = re_match_X(line)
>>     if m:
>>         gr1 = m.group(1)
>>         gr2 = m.group(2)
>>         etc ...
>>     elif (m = re_match_Y(line)):
>>         gr1 = m.group(1)
>>         gr2 = m.group(2)
>>         etc ...
>>  leading to really horrible conditional nesting - Yeuch! - whereas one can do it in Ruby:
>>       if line =~ /unquoted-regex-pattern-here/
>>         gr1 = $1
>>         gr2 = $2
>>         etc ...
>>     elsif line =~ /different-unquoted-regex-pattern-here/
>>         gr1 = $1
>>         gr2 = $2
>>         etc ...
>>  which keeps everything beautifully nice and neat.
>>  Note that in Ruby one can also use the RegEx class(es) explicitly, but I've never bothered, since the built-in stuff is so fabulously convenient. This and Ruby's ridiculously easy extension mechanism (c/w Python) are the two reasons I favour Ruby over everything - Python, Perl, C/C++, D - whenever I can. (With no disrespect intended, on the two occasions I've tried to use D's regex I've found it pales in comparison, and have prefered to write the program in Ruby.)
>>  Given my experience with Python and Ruby (and D), I personally strongly believe that built-in regex for D would be very popular. The downside is that it's coupling syntax with libraries. D does some of that already, but it's not a practice one should encourage in general. I believe that it'd be well worth it in this case, but I accept that others may not think so.
>>  Naturally I'd see this as a D 1.1 feature. I imagine it'd complicate things way too much now.
>>  Cheers
>>