View mode: basic / threaded / horizontal-split · Log in · Help
February 13, 2005
D Programming Language popularity index
http://www.tiobe.com/tpci.htm

We've risen to number 29!
February 13, 2005
Re: D Programming Language popularity index
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!
February 13, 2005
Re: D Programming Language popularity index
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!
>
>
February 13, 2005
Re: D Programming Language popularity index
> 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?
February 13, 2005
Re: D Programming Language popularity index - built-in regex
"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

-------------------------------------------------------------------------------
February 13, 2005
Re: D Programming Language popularity index - built-in regex
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
>
>-------------------------------------------------------------------------------
> 
>
>
February 13, 2005
Re: D Programming Language popularity index - built-in regex
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
>>
>>-------------------------------------------------------------------------------
>>
>>
>>
>
>
February 14, 2005
Re: D Programming Language popularity index - built-in regex
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
> 
>
February 14, 2005
Re: D Programming Language popularity index - built-in regex
:-)

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
>>>
>>>-------------------------------------------------------------------------------
>>>
>>>
>>>
>>
>> 
>
>
February 14, 2005
Re: D Programming Language popularity index - built-in regex
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
>>
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home