www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Programming Language popularity index

reply "Walter" <newshound digitalmars.com> writes:
http://www.tiobe.com/tpci.htm

We've risen to number 29!
Feb 13 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
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!
Feb 13 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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!

 

Feb 13 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 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?
Feb 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"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 -------------------------------------------------------------------------------
Feb 13 2005
next sibling parent reply Kris <Kris_member pathlink.com> writes:
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 -------------------------------------------------------------------------------

Feb 13 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
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 -------------------------------------------------------------------------------


Feb 13 2005
parent Kris <Kris_member pathlink.com> writes:
:-)

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 -------------------------------------------------------------------------------



Feb 13 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
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
 
 

Feb 13 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
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


Feb 13 2005
prev sibling next sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
     if line =~ /unquoted-regex-pattern-here/
         gr1 = $1
         gr2 = $2
         etc ...
 

Just off hand, suggesting this syntax for D scares the living daylights out of me. This opens up a can of worms the size of anacondas, IMHO, which would lead to D becoming like early versions of Perl, or unix shell scripting languages.
Feb 14 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:42106B14.4040503 nospam.org...
     if line =~ /unquoted-regex-pattern-here/
         gr1 = $1
         gr2 = $2
         etc ...

Just off hand, suggesting this syntax for D scares the living daylights out of me. This opens up a can of worms the size of anacondas, IMHO, which would lead to D becoming like early versions of Perl, or unix shell scripting languages.

Not blowing it out of proportion, or anything ... Ruby's managed perfectly well to have built-in regex syntax without this infinite doom that you predict.
Feb 14 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:42106B14.4040503 nospam.org...
 
    if line =~ /unquoted-regex-pattern-here/
        gr1 = $1
        gr2 = $2
        etc ...

Just off hand, suggesting this syntax for D scares the living daylights out of me. This opens up a can of worms the size of anacondas, IMHO, which would lead to D becoming like early versions of Perl, or unix shell scripting languages.

Not blowing it out of proportion, or anything ... Ruby's managed perfectly well to have built-in regex syntax without this infinite doom that you predict.

Ouch! :-( My sloppy writing. I think built-in regex syntax is ok. What I had a problem with was the gr1 = $1 stuff. _That_ gives me the creeps.
Feb 14 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4210F171.4090403 nospam.org...
 Matthew wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:42106B14.4040503 nospam.org...

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

Just off hand, suggesting this syntax for D scares the living daylights out of me. This opens up a can of worms the size of anacondas, IMHO, which would lead to D becoming like early versions of Perl, or unix shell scripting languages.

Not blowing it out of proportion, or anything ... Ruby's managed perfectly well to have built-in regex syntax without this infinite doom that you predict.

Ouch! :-( My sloppy writing. I think built-in regex syntax is ok. What I had a problem with was the gr1 = $1 stuff. _That_ gives me the creeps.

But if built-in is ok, why not use what is a de-facto standard for regex? That's what Ruby did, i.e. follow Perl's lead Of course it doesn't have to be $1, but if we're back to straight methods, I don't see much of an advantage over the Python way.
Feb 14 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:4210F171.4090403 nospam.org...
 
Matthew wrote:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:42106B14.4040503 nospam.org...


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

Just off hand, suggesting this syntax for D scares the living daylights out of me. This opens up a can of worms the size of anacondas, IMHO, which would lead to D becoming like early versions of Perl, or unix shell scripting languages.

Not blowing it out of proportion, or anything ... Ruby's managed perfectly well to have built-in regex syntax without this infinite doom that you predict.

Ouch! :-( My sloppy writing. I think built-in regex syntax is ok. What I had a problem with was the gr1 = $1 stuff. _That_ gives me the creeps.

But if built-in is ok, why not use what is a de-facto standard for regex? That's what Ruby did, i.e. follow Perl's lead Of course it doesn't have to be $1, but if we're back to straight methods, I don't see much of an advantage over the Python way.

I'm ok if it returns an array of strings. But, please, not the $ stuff!
Feb 14 2005
prev sibling parent reply Charles Hixson <charleshixsn earthlink.net> writes:
Matthew wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:4210F171.4090403 nospam.org...
 
Matthew wrote:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:42106B14.4040503 nospam.org...


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

Just off hand, suggesting this syntax for D scares the living daylights out of me. This opens up a can of worms the size of anacondas, IMHO, which would lead to D becoming like early versions of Perl, or unix shell scripting languages.

Not blowing it out of proportion, or anything ... Ruby's managed perfectly well to have built-in regex syntax without this infinite doom that you predict.

Ouch! :-( My sloppy writing. I think built-in regex syntax is ok. What I had a problem with was the gr1 = $1 stuff. _That_ gives me the creeps.

But if built-in is ok, why not use what is a de-facto standard for regex? That's what Ruby did, i.e. follow Perl's lead Of course it doesn't have to be $1, but if we're back to straight methods, I don't see much of an advantage over the Python way.

would be easy to do that in D. Just define a few variables like RE_1, etc. I seem to remember that the array form includes some mixed types, so it might not be possible to define RE[], but most of it's character array stuff.
Feb 14 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Charles Hixson" <charleshixsn earthlink.net> wrote in message 
news:curf17$272e$1 digitaldaemon.com...
 Matthew wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:4210F171.4090403 nospam.org...

Matthew wrote:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:42106B14.4040503 nospam.org...


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

Just off hand, suggesting this syntax for D scares the living daylights out of me. This opens up a can of worms the size of anacondas, IMHO, which would lead to D becoming like early versions of Perl, or unix shell scripting languages.

Not blowing it out of proportion, or anything ... Ruby's managed perfectly well to have built-in regex syntax without this infinite doom that you predict.

Ouch! :-( My sloppy writing. I think built-in regex syntax is ok. What I had a problem with was the gr1 = $1 stuff. _That_ gives me the creeps.

But if built-in is ok, why not use what is a de-facto standard for regex? That's what Ruby did, i.e. follow Perl's lead Of course it doesn't have to be $1, but if we're back to straight methods, I don't see much of an advantage over the Python way.

easy to do that in D. Just define a few variables like RE_1, etc. I seem to remember that the array form includes some mixed types, so it might not be possible to define RE[], but most of it's character array stuff.

That'd work, although they'd have to be thread-specific. Good idea!
Feb 14 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
  if line =~ /unquoted-regex-pattern-here/
      gr1 = $1
      gr2 = $2
      etc ...

living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";
Feb 15 2005
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Rather,

if (file1line =~ /unquoted-regex-pattern-here/)
{
    mystring = $3 ~ "bla" ~ $5;

    if ($3 < $8 && $9 == $1 || $3 > $2 && $5 =< ($2 ~ foo)
       mystring ~= $9 ~ "xx" ~ $3;
    else
    {
       if (file2line =~ /unquoted-regex-pattern-here/)
          mystring ~= $2 ~ $3 ~ " got out of hand!";
    }
    mystring ~= "\nAnd he never knew why.";
}

I guess?  Yes, that is out of hand - but that's just bad use of the 
feature.  I could take arrays or classes or something and do the same 
thing to them :P.

-[Unknown]


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

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Feb 15 2005
prev sibling next sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Is that supposed to be scary? It seems perfectly comprehensible to me. 
Or are you proving that it's not?

Confused ...

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:4211C3BE.3060402 nospam.org...
  if line =~ /unquoted-regex-pattern-here/
      gr1 = $1
      gr2 = $2
      etc ...

living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Feb 15 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 Is that supposed to be scary? It seems perfectly comprehensible to me. 
 Or are you proving that it's not?
 
 Confused ...

What's the value of $1 after the code snippet?
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:4211C3BE.3060402 nospam.org...
 
 if line =~ /unquoted-regex-pattern-here/
     gr1 = $1
     gr2 = $2
     etc ...

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";


Feb 15 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 15 Feb 2005 13:39:16 +0200, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Matthew wrote:
 Is that supposed to be scary? It seems perfectly comprehensible to me.  
 Or are you proving that it's not?
  Confused ...

What's the value of $1 after the code snippet?

So you're suggesting the problem is that $1 or r[0] may be replaced unintentionally in some cases... would this problem be obviated/solved if the r[] was returned explicitly i.e. r = regex.parse(/unquoted-regex-pattern-here/); I don't think so.. I suspect this problem is simply a problem with compex code, and while syntax may play a part in making it more or less likely, neither of these suggested syntax'es, to me, seems to make any difference in this respect.
 "Georg Wrede" <georg.wrede nospam.org> wrote in message  
 news:4211C3BE.3060402 nospam.org...

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

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";



Regan
Feb 15 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Regan Heath wrote:
 On Tue, 15 Feb 2005 13:39:16 +0200, Georg Wrede 
 <georg.wrede nospam.org>  wrote:
 Matthew wrote:


 syntax may play a part in making it more or less likely, neither of 
 these  suggested syntax'es, to me, seems to make any difference in this 
 respect.

I'm completely with you here! I've got an idea, but I'll have to check it first.
Feb 15 2005
prev sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Georg Wrede wrote:
  if line =~ /unquoted-regex-pattern-here/
      gr1 = $1
      gr2 = $2
      etc ...

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.
Feb 15 2005
next sibling parent reply "Charlie Patterson" <charliep1 excite.com> writes:
"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:cuth6l$165u$1 digitaldaemon.com...

 if file1line =~ /unquoted-regex-pattern-here/
 mystring = $3 ~ "bla" ~ $5;
 if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo)
     mystring ~= $9 ~ "xx" ~ $3;
 else {
     if file2line =~ /unquoted-regex-pattern-here/
     mystring ~= $2 ~ $3 ~ " got out of hand!";
 }
 mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Also, the alternative is to replace every $4 with Re[4], according to the original poster. That would be just as "line-noisy." I think the biggest issue with built-in string expressions is that you do approach that line-noise look which some people are repelled from: ~= /^Re$/
Feb 15 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Charlie Patterson wrote:
 "John Reimer" <brk_6502 yahoo.com> wrote in message 
 news:cuth6l$165u$1 digitaldaemon.com...
 
 
if file1line =~ /unquoted-regex-pattern-here/
mystring = $3 ~ "bla" ~ $5;
if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo)
    mystring ~= $9 ~ "xx" ~ $3;
else {
    if file2line =~ /unquoted-regex-pattern-here/
    mystring ~= $2 ~ $3 ~ " got out of hand!";
}
mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Also, the alternative is to replace every $4 with Re[4], according to the original poster. That would be just as "line-noisy." I think the biggest issue with built-in string expressions is that you do approach that line-noise look which some people are repelled from: ~= /^Re$/

How true. Additionally, in this example, we didn't even include the regex itself! So the code is getting illegible overall.
Feb 15 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
John Reimer wrote:
 Georg Wrede wrote:
 
  if line =~ /unquoted-regex-pattern-here/
      gr1 = $1
      gr2 = $2
      etc ...

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Yeah, but there is one bug already in this code, made by the "author" (i.e. me, writing the code). And there is another that'll hit him the second he starts writing the rest (of this imagined example). My problem is that neither you, nor Matthew, noticed it. So probably the average user, or the next guy won't either. Thus, I'm not happy with the syntax. --------- D can brag about being very easy to understand. Just browsing someone's code gives you immediately an idea of what's going on. But the above code takes a pencil and paper, and peace and quiet, before one can figure it out. I really see worms and anacondas taking over, if we we unlock the door and let Larry Wall in.
Feb 15 2005
next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <42125F89.2070109 nospam.org>, Georg Wrede says...
John Reimer wrote:
 Georg Wrede wrote:
 
  if line =~ /unquoted-regex-pattern-here/
      gr1 = $1
      gr2 = $2
      etc ...

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Yeah, but there is one bug already in this code, made by the "author" (i.e. me, writing the code). And there is another that'll hit him the second he starts writing the rest (of this imagined example). My problem is that neither you, nor Matthew, noticed it. So probably the average user, or the next guy won't either. Thus, I'm not happy with the syntax. --------- D can brag about being very easy to understand. Just browsing someone's code gives you immediately an idea of what's going on. But the above code takes a pencil and paper, and peace and quiet, before one can figure it out. I really see worms and anacondas taking over, if we we unlock the door and let Larry Wall in.

Yeah. One major problem, as I see it, with this syntax is the anonymous nature of the $ references. I presume these are supposed to refer to numbered sub-patterns, yes? From my perspective, this would be much better served using structs with <gasp> named members instead: ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))? 12 3 4 5 6 7 8 9 struct Uri_RFC2396 { char[] uri, protocol, scheme, resource, authority, path, args, query, tail, fragment; } If one could pass this off to the RegExp and have it filled in, then so much the better. One might make the struct a union if need be (with a char[][10]). One could also give the members really obtuse names if so desired (a, b, c, d, e, f ..), and end up with vague 3 letter abbreviations instead of 2 In addition to readability & maintainability, the primary benefit is via the lack of implicit global variables (or thread-locals), coupled with the privacy, utility, and speedy access of stack-based structures. Heck, you could place the struct on the heap if you needed to; or even make it a global if you feel lucky. The point is that you have a choice. I sure hope D does not end up looking like, ahh, APL :-)
Feb 15 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Eeew.... so I'd have to do a struct of ugly proportions for something 
this simple? (yes I know it could also likely be done with sscanf and 
indeed it would probably be faster...)

// Check memcached return value...
if (stream.readLine() ~= /^VALUE [^\s]+ (\d+)/i)
{
    value = stream.readString(atoi(matches[1]));

    // Skip the \r\n...
    assert(stream.getc() == '\r');
    assert(stream.getc() == '\n');
}

So some sort of struct like:

struct SomeHatefulDummyStruct
{
    char[] matchedData; // $0
    char[] firstMatch;  // $1
}

I don't know about you, but I can't stand that.  The code could be so 
simple, so readable (assuming you understand my basic code practices, 
which I would of course have documented elsewhere and would be common 
enough that most people would recognize them.)  Instead I have to have a 
dummy struct?  Why?

I suppose it'd be nice, for the really long ugly cases where you 
probably shouldn't be using a regular expression anyway... but what 
about the simple ones where introducing identifiers the reader has to 
look up is only going to complicate things?

-[Unknown]

 Yeah. 
 
 One major problem, as I see it, with this syntax is the anonymous nature of the
 $ references. I presume these are supposed to refer to numbered sub-patterns,
 yes?
 
 From my perspective, this would be much better served using structs with <gasp>
 named members instead:
 
 ^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
 12            3  4          5       6  7        8 9
 
 struct Uri_RFC2396
 {
 char[] uri,
 protocol,
 scheme,
 resource,
 authority,
 path,
 args,
 query,
 tail,
 fragment;
 }
 
 If one could pass this off to the RegExp and have it filled in, then so much
the
 better. One might make the struct a union if need be (with a char[][10]). One
 could also give the members really obtuse names if so desired (a, b, c, d, e, f
 ..), and end up with vague 3 letter abbreviations instead of 2
 
 In addition to readability & maintainability, the primary benefit is via the
 lack of implicit global variables (or thread-locals), coupled with the privacy,
 utility, and speedy access of stack-based structures. Heck, you could place the
 struct on the heap if you needed to; or even make it a global if you feel
lucky.
 The point is that you have a choice. 
 
 I sure hope D does not end up looking like, ahh, APL :-)
 
 

Feb 15 2005
parent reply kris <fu bar.org> writes:
Unknown W. Brackets wrote:
 Eeew.... so I'd have to do a struct of ugly proportions for something 
 this simple? (yes I know it could also likely be done with sscanf and 
 indeed it would probably be faster...)
 
 // Check memcached return value...
 if (stream.readLine() ~= /^VALUE [^\s]+ (\d+)/i)
 {
    value = stream.readString(atoi(matches[1]));
 
    // Skip the \r\n...
    assert(stream.getc() == '\r');
    assert(stream.getc() == '\n');
 }
 
 So some sort of struct like:
 
 struct SomeHatefulDummyStruct
 {
    char[] matchedData; // $0
    char[] firstMatch;  // $1
 }
 
 I don't know about you, but I can't stand that.  The code could be so 
 simple, so readable (assuming you understand my basic code practices, 
 which I would of course have documented elsewhere and would be common 
 enough that most people would recognize them.)  Instead I have to have a 
 dummy struct?  Why?

You don't have to, if you don't want to. You might use a predefined struct with anonymous names. Perhaps it might be something like this: (hope the spaces don't get mashed ...) module std.RegExp; struct Patterns { char[] p1, p2, p3, etc ... // or a, b, c, d ... } Followed by: import std.RegExp; Patterns pattens; ... with (patterns) { if (p1) ... } and so on. The 'with' statement can be quite handy for such things.
 I suppose it'd be nice, for the really long ugly cases where you 
 probably shouldn't be using a regular expression anyway... 

Why ever not? Complex pattern matching is what regex typically excels at. A url is a fairly jolly example, is it not? If Speed is the #1 priority, then I would unwind the parse into dedicated and hand-tweaked code. Where convenience is king, regex can be awesome.
 but what 
 about the simple ones where introducing identifiers the reader has to 
 look up is only going to complicate things?

Are you saying that using '$3' somehow magically trancends the need to locate and mentally parse the original regex pattern? To see what '$3' refers to? The point of using descriptive names is to avoid that :-) This is the same principle as used when folk apply descriptive names to program variables; so one doesn't have to search out the last assignment assignment to see what the dashed thing represents. These sub-patterns *are* program variables; they just happen to be related to one particular type of functionality (all the more reason why containment should be applied). Still, one can always use the predefined 'anonymous' struct instead; in the same fashion as we often use 'int i'. If $1 and $7 are so blindingly obvious, then: with (patterns) { p1 ~= p7; ... } should be just as obvious. Yes? And let's not forget opCall ... one can use that quite effectively when trying to reduce syntactic sugar. These are just suggestions. There's a whole raft of issues to be resolved if this stuff were to be built-in instead. I think we should explore the possibilities open to us with the current compiler and, again, this approach allows a set of choices over how the sub-patterns are managed, stored, and named. If we keep chipping away at it, it can only get better.
Feb 15 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
You just succeeded in raping and pillaging my example.  I said, in 
simple cases.... for one, "p7" would never happen in simple cases.

There's no way to tell what p1 is, you're right.  There's no regular 
expression.  Kris, if I gave you this code:

int grabTheURL()
{
    return globals_definedURL;
}

What does it do?  Got any idea?  Well, for one thing the code is missing 
documentation (and uses icky globals.)  What makes programmers think 
they can get away with not commenting their code will never make sense 
to me; I always comment my code, and hence I *ALWAYS* get comments about 
how readable, clean, and organized my code is.  And, yes, for your 
information I do use $1, i, j, k, etc. - and yet people still say this. 
  Funny.

Context and commenting are what REALLY matter, even in complicated 
examples.  We could keep trading examples and get nowhere.  The fact is, 
this:

if (url ~= /^http:\/\/(.+)$/)
    url = $1;

Is just as self explanatory as:

for (int i = 0; i < url.length; i++)

If it's not, the person at fault is not the programmer, but rather the 
reader.  I'm sorry if that sounds harsh.  However, it should of course 
be commented when at all necessary:

// Strip off the http:// because we know it's HTTP.
if (url ~= /^http:\/\/(.+)$/)
    url = $1;

If you really think this is MORE readable and MORE self explanatory:

// Strip off the http:// because we know it's HTTP.
Parameters parameters;
if (new Regexp(`^http://(.+)$`, "").test(url, parameters))
{
    with (parameters)
       url = p1;
}

Or, perhaps:

// Strip off the http:// because we know it's HTTP.
HTTPStripper parameters;
if (new Regexp(`^http://(.+)$`, "").test(url, parameters))
    url = parameters.urlWithoutHttp;

Then we must simply think differently.  For one thing, the second 
example looks more complicated and "scary".  What's this "HTTPStripper" 
thing?  Gotta go look it up... oh, it's just a struct with fullMatch and 
urlWithoutHttp in it.  What's fullMatch?  Doesn't appear to be used... 
err... weird... I don't understand it.  That's what people reading my 
code will say to the last two examples.

Then again, I'm more of an open source guy.  I want my code to be fast, 
effecient, clean, understandable, structured, and most importantly 
commented.  I don't think adding identifiers or using longer names where 
completely unecessary (e.g. when the variable is only used the once and 
a comment can make it 100% clear) acheives any of the above goals.

Yes, it's just syntactical sugar, perhaps, but arguing against it 
because it's less readable... well, that's like saying driving a car 
(whatever your age) should be illegal because doing so can kill people. 
  Okay, that's true, but should it be illegal?

-[Unknown]


 with (patterns)
      {
      p1 ~= p7;
      ...
      }
 
 should be just as obvious. Yes?
 
 And let's not forget opCall ... one can use that quite effectively when 
 trying to reduce syntactic sugar.

Feb 16 2005
next sibling parent reply Kris <Kris_member pathlink.com> writes:
In article <cuuvfm$2j2a$1 digitaldaemon.com>, Unknown W. Brackets says...
You just succeeded in raping and pillaging my example.  I said, in 
simple cases.... for one, "p7" would never happen in simple cases.

Sorry ~ wasn't intentional.
Then again, I'm more of an open source guy.  I want my code to be fast, 
effecient, clean, understandable, structured, and most importantly 
commented.  I don't think adding identifiers or using longer names where 
completely unecessary (e.g. when the variable is only used the once and 
a comment can make it 100% clear) acheives any of the above goals.

There's perhaps a vague implication in there that I, personally, take a different stand. Which, of course, is simply not true.
Yes, it's just syntactical sugar, perhaps, but arguing against it 
because it's less readable... well, that's like saying driving a car 
(whatever your age) should be illegal because doing so can kill people. 
  Okay, that's true, but should it be illegal?

I think this aspect of the thread is rapidly veering off the road. I'm certainly not against a built-in Regex based solely upon naming conventions. That's simply one observation on a long-standing tradition (regex itself is a bit cryptic, so why shouldn't the identifiers be, too?). No; the real issue is with respect to global variables, thread-locals, encapsulation, and whatever else one wishes to throw into that basket. The fact is that match() is a function emitting a (potential) set of sub-matches, an indication of success, and an index into the matched content. In other words, it is a multi-return function. This thread was started with a suggestion to give that particular function very, very, special standing within D by making its multi-return values inherent within the language spec. I think that's overlooking what D can support right now for such cases, and it would introduce a raft of other issues related to that lack of encapsulation noted previously. I'm really not even vaguely interested in debating syntactical or stylistic preferences with anyone. What I will bitch and whine about is a notion to introduce special syntax into the language (along with a bunch of potential scoping,liveness, and concurreny problems) when the functionality can be supported perfectly well with the language as it is, without creating further special-case scenarios. Further, given the 'positive' argument for a built-in syntax, there's been a conspicuous absence of resolution for the lack of encapsulation and so on. Sure, one can argue all day long about how some built-in syntax for such a notion can be made to look more attractive (or more cryptic) than leveraging the existing capabilites. But why bother? If the primary purpose of D were to be a regex language, then perhaps there'd be a point to all this. Yet that is simply not the case. Thus, I feel we should look for a way to make RegExp as 'acceptable' to all concerned, whilst taking advantage of what we already have with the current language constructs. If you don't think that's even possible or desirable, then we should abate right now :-) What are your thoughts, Matthew? - Kris
Feb 16 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 No; the real issue is with respect to global variables, thread-locals,
 encapsulation, and whatever else one wishes to throw into that basket. 
 The fact
 is that match() is a function emitting a (potential) set of 
 sub-matches, an
 indication of success, and an index into the matched content. In other 
 words, it
 is a multi-return function.

 This thread was started with a suggestion to give that particular 
 function very,
 very, special standing within D by making its multi-return values 
 inherent
 within the language spec. I think that's overlooking what D can 
 support right
 now for such cases, and it would introduce a raft of other issues 
 related to
 that lack of encapsulation noted previously.

 I'm really not even vaguely interested in debating syntactical or 
 stylistic
 preferences with anyone. What I will bitch and whine about is a notion 
 to
 introduce special syntax into the language (along with a bunch of 
 potential
 scoping,liveness, and concurreny problems) when the functionality can 
 be
 supported perfectly well with the language as it is, without creating 
 further
 special-case scenarios.

 Further, given the 'positive' argument for a built-in syntax, there's 
 been a
 conspicuous absence of resolution for the lack of encapsulation and so 
 on.

 Sure, one can argue all day long about how some built-in syntax for 
 such a
 notion can be made to look more attractive (or more cryptic) than 
 leveraging the
 existing capabilites. But why bother? If the primary purpose of D were 
 to be a
 regex language, then perhaps there'd be a point to all this. Yet that 
 is simply
 not the case.

 Thus, I feel we should look for a way to make RegExp as 'acceptable' 
 to all
 concerned, whilst taking advantage of what we already have with the 
 current
 language constructs. If you don't think that's even possible or 
 desirable, then
 we should abate right now :-)

 What are your thoughts, Matthew?

There are several comments one would make: - given that D already has an uncomfortable (to some at least) coupling between language and library (Object.print(), anyone?), one might say that one more _worthy_ case should be considered - there's a general principle - often ascribed to B.S. himself - that anything that can be handled in a library has no business being in the language. This is a very wise principle. - there's the practical fact that using regex in Python is a pain, and in C++ it's downright torture. (Same can be said of D, IMO and IMLX) so, I'm somewhat straddling the spikey spikes here: I'm coming down on the side of "with()" for scoping the variables, since they must, at worst, be thread-local. Even when thread-local, one must be very careful about re-entrancy. (What if D evolves - as I think it should - to allow custom implicit toString() stuff and inside such a toString() another regex is used. Nasty!) However, I'm also informed by (as I acknowledge, my (not im)partial) experience of how disheartening doing regexp in anything other than Perl & Ruby is. Maybe my position is something like: - in principle, language and library should always be maximally independent. However, given that they are not, and cannot be, in D, we should have our minds ever so slightly open to VERY IMPORTANT CASES. - assuming for the moment that we agree that regex is a VERY IMPORTANT CASE, then we must ensure that use of the regexp is maximally convenient, maximally conventional, while not betraying D's aims of robust, being thread-safe, programmer protective (albeit not programmer 'cossetive' / responsibility abbrogative), efficient, maintainable, etc. - this means that D *cannot* use process-local global variables for pattern matches. Furthermore, thread-local globals are still not safe from intra-thread re-entrancy. That being the case, the issue of using $1 syntax is moot, so we most certainly should use with(). At this point I think rather than making any further half-arsed prognostications, I should maybe go and play with D's existing regexp more, and identify the specific things that turned me off it so much in the past. Then maybe that'll inform, at least for me, on any future ideas. Derek the D i t h e r e d
Feb 16 2005
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
 Context and commenting are what REALLY matter, even in complicated 
 examples.  We could keep trading examples and get nowhere.  The fact 
 is, this:

 if (url ~= /^http:\/\/(.+)$/)
    url = $1;

 Is just as self explanatory as:

 for (int i = 0; i < url.length; i++)

Agreed.
 If it's not, the person at fault is not the programmer, but rather the 
 reader.  I'm sorry if that sounds harsh.

Agreed, in this case. Because regexp is a very widely recognised, valued, and understood para-language. If anyone's using regexp _in any language_, then they need to understand it. The myriad possible configurations of squiggles that go to make up the expression make any confusion of use of $n irrelevant. I can truthfully say I've _never_ experienced a single moment of confusion about the use of matched groups in regexp-client code; of course that cannot be said wrt the expressions themselves (they're a daily cause for crying).
  However, it should of course be commented when at all necessary:

 // Strip off the http:// because we know it's HTTP.
 if (url ~= /^http:\/\/(.+)$/)
    url = $1;

 If you really think this is MORE readable and MORE self explanatory:

 // Strip off the http:// because we know it's HTTP.
 Parameters parameters;
 if (new Regexp(`^http://(.+)$`, "").test(url, parameters))
 {
    with (parameters)
       url = p1;
 }

 Or, perhaps:

 // Strip off the http:// because we know it's HTTP.
 HTTPStripper parameters;
 if (new Regexp(`^http://(.+)$`, "").test(url, parameters))
    url = parameters.urlWithoutHttp;

These are less clear, to be sure. But they're not 'unclear'. Indeed, the with() idea does help with a lot of valid objections to the global nature of matched groups.
 Then we must simply think differently.  For one thing, the second 
 example looks more complicated and "scary".  What's this 
 "HTTPStripper" thing?  Gotta go look it up... oh, it's just a struct 
 with fullMatch and urlWithoutHttp in it.  What's fullMatch?  Doesn't 
 appear to be used... err... weird... I don't understand it.  That's 
 what people reading my code will say to the last two examples.

For my part, I can live with with(), but the non-built-in-ness of the regexp itself is not attractive.
 Then again, I'm more of an open source guy.  I want my code to be 
 fast, effecient, clean, understandable, structured, and most 
 importantly commented.  I don't think adding identifiers or using 
 longer names where completely unecessary (e.g. when the variable is 
 only used the once and a comment can make it 100% clear) acheives any 
 of the above goals.

This is all a bit off point, methinks
 Yes, it's just syntactical sugar, perhaps, but arguing against it 
 because it's less readable... well, that's like saying driving a car 
 (whatever your age) should be illegal because doing so can kill 
 people. Okay, that's true, but should it be illegal?

Please put the top back on that worm can immediately! :-)
Feb 16 2005
prev sibling next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
Georg Wrede wrote:
 
 
 John Reimer wrote:
 
 Georg Wrede wrote:

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

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Yeah, but there is one bug already in this code, made by the "author" (i.e. me, writing the code). And there is another that'll hit him the second he starts writing the rest (of this imagined example). My problem is that neither you, nor Matthew, noticed it. So probably the average user, or the next guy won't either. Thus, I'm not happy with the syntax. --------- D can brag about being very easy to understand. Just browsing someone's code gives you immediately an idea of what's going on. But the above code takes a pencil and paper, and peace and quiet, before one can figure it out. I really see worms and anacondas taking over, if we we unlock the door and let Larry Wall in.

Frankly, I didn't look at this as an exercise in bug-hunting. I thought the point of the post was to show how ugly the $ sign notation was. Thus my response to the contrary. So the fact that I didn't notice the problem is of no relevance. I'm not too surprised that you could make a buggy example out of a not-yet-defined D syntax. Someone else could make a non-buggy example too, I'm sure, with a nice, clear presentation. I was just musing that, aesthetically, it looked tolerable. This doesn't rule out the possibility of a better way, of course; and, by far, I'm in no position to offer any expert opinion on what that way might be. Matthew on the other hand... Later, John
Feb 15 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"John Reimer" <brk_6502 yahoo.com> wrote in message 
news:cuuoes$2c4h$1 digitaldaemon.com...
 Georg Wrede wrote:
 John Reimer wrote:

 Georg Wrede wrote:

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

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Yeah, but there is one bug already in this code, made by the "author" (i.e. me, writing the code). And there is another that'll hit him the second he starts writing the rest (of this imagined example). My problem is that neither you, nor Matthew, noticed it. So probably the average user, or the next guy won't either. Thus, I'm not happy with the syntax. --------- D can brag about being very easy to understand. Just browsing someone's code gives you immediately an idea of what's going on. But the above code takes a pencil and paper, and peace and quiet, before one can figure it out. I really see worms and anacondas taking over, if we we unlock the door and let Larry Wall in.

Frankly, I didn't look at this as an exercise in bug-hunting. I thought the point of the post was to show how ugly the $ sign notation was. Thus my response to the contrary. So the fact that I didn't notice the problem is of no relevance. I'm not too surprised that you could make a buggy example out of a not-yet-defined D syntax. Someone else could make a non-buggy example too, I'm sure, with a nice, clear presentation. I was just musing that, aesthetically, it looked tolerable. This doesn't rule out the possibility of a better way, of course; and, by far, I'm in no position to offer any expert opinion on what that way might be. Matthew on the other hand...

... what? :-) If you mean expert, I'm not. This whole sub-thread came from my experience in doing lots of regexp in Perl, Python and Ruby and some in C++ and D. There's no expertise, no theoretical basis to what I say, just the facts (from my pov) of my experience. Just this morning I was able to come back to Ruby from Python (this is because I didn't need XML and I _did_ need recls; the recls/Python mapping's not done yet), and it was like that wonderful feeling of getting home after a long hard day in a client's office, debating the relative merits of whether we should go to production on the basis of unit testing only. I'm not saying "D must have built-in regex", nor am I saying that "D's built-in regex must use Perl/Ruby syntax for the matched groups", but I am saying that "I believe that if D has built-in regex it will be more generally useful, and therefore more popular/successful, than if it does not". If we don't have $1, $2, but we do have, say (thread-specific) _1, _2 etc., then I'd be content with that. As for the buggy-code, I'd say it's a furphy in the extreme. Again, and this is only me speaking from my own experience, I've found the built-in way is _far_, _far_, _far_ (three times - must be a poltician) easier to get correct first time than when having to use a function call based approach.
Feb 16 2005
prev sibling next sibling parent "Charlie Patterson" <charliep1 excite.com> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:42125F89.2070109 nospam.org...

 if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo)
     mystring ~= $9 ~ "xx" ~ $3;
 else {
     if file2line =~ /unquoted-regex-pattern-here/
     mystring ~= $2 ~ $3 ~ " got out of hand!";
 }



 Actually, it doesn't look all that bad.


 D can brag about being very easy to understand. Just browsing
 someone's code gives you immediately an idea of what's
 going on. But the above code takes a pencil and paper,
 and peace and quiet, before one can figure it out.

I'm not pushing for regex in D, but... Sometimes a simplified line of code may be worth a paper and pencil to "decipher". Think of math. One integral equation can take a book to explain in detail, but it is nice to have a perfect and complete description in one line. In other words, an obtuse looking regular expression may parse an entire, compicated line of input. The alternative is to write 50 lines of code with trims and splices and ifs and substrs. It might look easier at first glance (less like line-noise), but it will take just as much time to work through the intricacies of those 50 lines of trim(toupper(substr( blah, 3, 9))). Once your get more comfortable with regexes, you will see lots of useful idioms and you can actually read complex parsing code faster.
Feb 16 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:42125F89.2070109 nospam.org...
 John Reimer wrote:
 Georg Wrede wrote:

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

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Yeah, but there is one bug already in this code, made by the "author" (i.e. me, writing the code). And there is another that'll hit him the second he starts writing the rest (of this imagined example). My problem is that neither you, nor Matthew, noticed it. So probably the average user, or the next guy won't either. Thus, I'm not happy with the syntax.

I wasn't looking at it in that way. I don't look at _any_ code on ng posts for bugworthiness. That's what I do in code reviews, or in development of code, or when determining whether or not a particular library has enough merit to bother unzipping it. On ngs, I assume we're talking 'concept' and glimpse code for its feel. Hence, I wouldn't read anything into my having not seen the bug, since I didn't even delve into what the code did. I took it in the spirit of the context of the discussion at that time.
 ---------

 D can brag about being very easy to understand. Just browsing
 someone's code gives you immediately an idea of what's
 going on. But the above code takes a pencil and paper,
 and peace and quiet, before one can figure it out.

 I really see worms and anacondas taking over, if we
 we unlock the door and let Larry Wall in.

I'm sure Regan would be better able to give a definitive logical objection here, but it seems like the conclusion you've drawn has had at least one hopeful leap from the premise of earlier in the post.
Feb 16 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 17 Feb 2005 10:55:05 +1100, Matthew  
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message
 news:42125F89.2070109 nospam.org...
 John Reimer wrote:
 Georg Wrede wrote:

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

Just off hand, suggesting this syntax for D scares the living daylights out of me.






if file1line =~ /unquoted-regex-pattern-here/ mystring = $3 ~ "bla" ~ $5; if ($3<$8 && $9==$1 || $3>$2 && $5=<($2 ~ foo) mystring ~= $9 ~ "xx" ~ $3; else { if file2line =~ /unquoted-regex-pattern-here/ mystring ~= $2 ~ $3 ~ " got out of hand!"; } mystring ~= "\nAnd he never knew why.";

Actually, it doesn't look all that bad.

Yeah, but there is one bug already in this code, made by the "author" (i.e. me, writing the code). And there is another that'll hit him the second he starts writing the rest (of this imagined example). My problem is that neither you, nor Matthew, noticed it. So probably the average user, or the next guy won't either. Thus, I'm not happy with the syntax.

I wasn't looking at it in that way. I don't look at _any_ code on ng posts for bugworthiness. That's what I do in code reviews, or in development of code, or when determining whether or not a particular library has enough merit to bother unzipping it. On ngs, I assume we're talking 'concept' and glimpse code for its feel. Hence, I wouldn't read anything into my having not seen the bug, since I didn't even delve into what the code did. I took it in the spirit of the context of the discussion at that time.
 ---------

 D can brag about being very easy to understand. Just browsing
 someone's code gives you immediately an idea of what's
 going on. But the above code takes a pencil and paper,
 and peace and quiet, before one can figure it out.

 I really see worms and anacondas taking over, if we
 we unlock the door and let Larry Wall in.

I'm sure Regan would be better able to give a definitive logical objection here, but it seems like the conclusion you've drawn has had at least one hopeful leap from the premise of earlier in the post.

I'll post my link again: http://www.infidels.org/news/atheism/logic.html It describes the form of a deductive argument using boolean logic, how/when it's useful and how to go about it in addition to common fallacies in logic. In this case it sounds like Matthew disagrees with an earlier premise or the inference from an earlier premise to a later one. Regan
Feb 16 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
On Thu, 17 Feb 2005 13:39:35 +1300, Regan Heath wrote:

 I'll post my link again:
 http://www.infidels.org/news/atheism/logic.html
 
 It describes the form of a deductive argument using boolean logic,  
 how/when it's useful and how to go about it in addition to common  
 fallacies in logic.
 
 In this case it sounds like Matthew disagrees with an earlier premise or  
 the inference from an earlier premise to a later one.
 
 Regan

Atheism and logic ... hmmm. Seems like there's a faulty premise there. :-)
Feb 16 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 16 Feb 2005 16:53:14 -0800, John Reimer <brk_6502 yahoo.com> wrote:

 On Thu, 17 Feb 2005 13:39:35 +1300, Regan Heath wrote:

 I'll post my link again:
 http://www.infidels.org/news/atheism/logic.html

 It describes the form of a deductive argument using boolean logic,
 how/when it's useful and how to go about it in addition to common
 fallacies in logic.

 In this case it sounds like Matthew disagrees with an earlier premise or
 the inference from an earlier premise to a later one.

 Regan

Atheism and logic ... hmmm. Seems like there's a faulty premise there. :-)

I tend to agree, but lets no go there. :) Regan
Feb 16 2005
parent John Reimer <brk_6502 yahoo.com> writes:
On Thu, 17 Feb 2005 14:08:12 +1300, Regan Heath wrote:

 On Wed, 16 Feb 2005 16:53:14 -0800, John Reimer <brk_6502 yahoo.com> wrote:
 
 On Thu, 17 Feb 2005 13:39:35 +1300, Regan Heath wrote:

 I'll post my link again:
 http://www.infidels.org/news/atheism/logic.html

 It describes the form of a deductive argument using boolean logic,
 how/when it's useful and how to go about it in addition to common
 fallacies in logic.

 In this case it sounds like Matthew disagrees with an earlier premise or
 the inference from an earlier premise to a later one.

 Regan

Atheism and logic ... hmmm. Seems like there's a faulty premise there. :-)

I tend to agree, but lets no go there. :) Regan

He he... good call. I don't think I'm up to one of those endless debates either.
Feb 16 2005
prev sibling next sibling parent reply John Reimer <brk_6502 yahoo.com> writes:
On Thu, 17 Feb 2005 10:55:05 +1100, Matthew wrote:

 I'm sure Regan would be better able to give a definitive logical 
 objection here, but it seems like the conclusion you've drawn has had at 
 least one hopeful leap from the premise of earlier in the post.

No, No, No. please, no.... Did you have to do that?! What an invitation. :-(
Feb 16 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 16 Feb 2005 16:47:04 -0800, John Reimer <brk_6502 yahoo.com> wrote:

 On Thu, 17 Feb 2005 10:55:05 +1100, Matthew wrote:

 I'm sure Regan would be better able to give a definitive logical
 objection here, but it seems like the conclusion you've drawn has had at
 least one hopeful leap from the premise of earlier in the post.

No, No, No. please, no.... Did you have to do that?! What an invitation. :-(

Yeah, I couldn't resist. Either he wanted me to, or he was .. either way I thought I'd play my part. Regan
Feb 16 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 I wasn't looking at it in that way. I don't look at _any_ code on ng 
 posts for bugworthiness. That's what I do in code reviews, or in 
 development of code, or when determining whether or not a particular 
 library has enough merit to bother unzipping it. On ngs, I assume we're 
 talking 'concept' and glimpse code for its feel.
 
 Hence, I wouldn't read anything into my having not seen the bug, since I 
 didn't even delve into what the code did. I took it in the spirit of the 
 context of the discussion at that time.

Oh, what a shame. I made such a great effort in introducing the two bugs. ;-) Honestly, I too read the examples here the way you do, but writing mine, I kinda forgot about it. ( Not to mention the bugs i later found, that I didn't intend on. ;-( )
Feb 17 2005
parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:421461E4.5070004 nospam.org...
 Matthew wrote:
 I wasn't looking at it in that way. I don't look at _any_ code on ng 
 posts for bugworthiness. That's what I do in code reviews, or in 
 development of code, or when determining whether or not a particular 
 library has enough merit to bother unzipping it. On ngs, I assume 
 we're talking 'concept' and glimpse code for its feel.

 Hence, I wouldn't read anything into my having not seen the bug, 
 since I didn't even delve into what the code did. I took it in the 
 spirit of the context of the discussion at that time.

Oh, what a shame. I made such a great effort in introducing the two bugs. ;-) Honestly, I too read the examples here the way you do, but writing mine, I kinda forgot about it. ( Not to mention the bugs i later found, that I didn't intend on. ;-( )

He. nw. :-)
Feb 17 2005
prev sibling parent __me <__me_member pathlink.com> writes:
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.

Instead I'd prefer if the language would be extended so you can re-built the ruby-synthax (or something similar) on your own. I don't have an idea how to do that. But there are languages that have something they normaly call macro. You can directly work on the AST generated by the compiler and change them. But those languages are normaly languages with a VM. So I don't know if this could be implemented in D.
Feb 14 2005
prev sibling next sibling parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Matthew schrieb:
 All we need now is to use that reserved $ for built-in regex, and D will 
 be on its way to top place. :-)

I've been thinking along that line as well. There is a clear advantage of compile-time regexps. Just consider the fact that in Python, you have to call 'compile' on regexps before you can use it. This already makes clear, that the translation from a regexp in string form to a regexp in executable representation basically is a compilation step which costs run-time performace. An alternative approach to the issue would be, though, to enhance the template-meta language in such a way that regexps can be translated at compile-time. What would that mean? * All string manipulations would have to be done at compile time. I cannot see yet, how that might be possible with char[]. Maybe it is yet a reason for a native string-type that can be handled at compile time in some way. * It would simplify matters, if calls to side-effect-free functions with constant arguments were executed at compile time, returning constant values. This C++, the lack of this feature can be worked around by tricky template programming, but that can become rather awkward for more complicated computations. * one would need to handle nested data-structures at compile time. I have no clear vision yet how that might fit into the language. Maybe it is possible to (ab)use templates in a clever way to do that. Apart from these very specific points, the compile-time language would just need to be enhanced in general. So far, template meta-programming can be done to some extent, but neither language nor compiler are really up to the task yet (for the compiler, just consider the minimalistic error messages when using nested templates...)
Feb 13 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Norbert Nemec" <Norbert Nemec-online.de> wrote in message 
news:cupkc2$30jf$1 digitaldaemon.com...
 Matthew schrieb:
 All we need now is to use that reserved $ for built-in regex, and D will 
 be on its way to top place. :-)

I've been thinking along that line as well. There is a clear advantage of compile-time regexps. Just consider the fact that in Python, you have to call 'compile' on regexps before you can use it. This already makes clear, that the translation from a regexp in string form to a regexp in executable representation basically is a compilation step which costs run-time performace.

I could see another string prefix for patterns that looks like the r"..." for raw strings. Something like p"..." would compile the pattern at compile-time instead of run-time. I bet, though, that the time spent in compiling a pattern at run-time is small compared to the time spent "running" the pattern. The downside as other people mentioned is that the format of the compiled pattern would have to match whatever the library expects. Most of the benefits to building it in would be for syntax. I wonder if some magic manipulation of "with" could help without having to change the language.
 An alternative approach to the issue would be, though, to enhance the 
 template-meta language in such a way that regexps can be translated at 
 compile-time.

That sounds interesting and fun to try. Do you think it would address the syntax issues, though?
Feb 14 2005
parent reply Norbert Nemec <Norbert Nemec-online.de> writes:
Ben Hinkle schrieb:
 "Norbert Nemec" <Norbert Nemec-online.de> wrote in message 
 news:cupkc2$30jf$1 digitaldaemon.com...
 
Matthew schrieb:

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

I've been thinking along that line as well. There is a clear advantage of compile-time regexps. Just consider the fact that in Python, you have to call 'compile' on regexps before you can use it. This already makes clear, that the translation from a regexp in string form to a regexp in executable representation basically is a compilation step which costs run-time performace.

I could see another string prefix for patterns that looks like the r"..." for raw strings. Something like p"..." would compile the pattern at compile-time instead of run-time. I bet, though, that the time spent in compiling a pattern at run-time is small compared to the time spent "running" the pattern. The downside as other people mentioned is that the format of the compiled pattern would have to match whatever the library expects.

Depends on what you call 'compiling'. Your words remind me more of 'parsing' - and returning the pattern in some pre-digested format that can then be used be the matching library. What I was thinking of would be to produce actual executable code from the string-representation. And here, the compiler could do all kinds of optimizations on a given pattern.
An alternative approach to the issue would be, though, to enhance the 
template-meta language in such a way that regexps can be translated at 
compile-time.

That sounds interesting and fun to try. Do you think it would address the syntax issues, though?

Not without the language allowing some more flexibility. So far, Walter runs a rather strict line on limiting the use of operators. There is some good justification for that, but it also means that for every additional operator used be the library, you'll need Walters blessing first. In that situation, it will never be easy to do fundamental extension purely in the library.
Feb 16 2005
parent Georg Wrede <georg.wrede nospam.org> writes:
Norbert Nemec wrote:
 Ben Hinkle schrieb:
 "Norbert Nemec" <Norbert Nemec-online.de>
 Matthew schrieb:

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

I've been thinking along that line as well. There is a clear advantage of compile-time regexps. Just consider the fact that in Python, you have to call 'compile' on regexps before you can use it. This already makes clear, that the translation from a regexp in string form to a regexp in executable representation basically is a compilation step which costs run-time performace.

I could see another string prefix for patterns that looks like the r"..." for raw strings. Something like p"..." would compile the pattern at compile-time instead of run-time. I bet, though, that the time spent in compiling a pattern at run-time is small compared to the time spent "running" the pattern. The downside as other people mentioned is that the format of the compiled pattern would have to match whatever the library expects.

Depends on what you call 'compiling'. Your words remind me more of 'parsing' - and returning the pattern in some pre-digested format that can then be used be the matching library. What I was thinking of would be to produce actual executable code from the string-representation. And here, the compiler could do all kinds of optimizations on a given pattern.

What if we just consider an Unquoted Regular Expression as just another piece of program code? It is, after all, only program code, albeit written with a syntax of its own. Then we might decide on a fixed signature for such. This would make it easy for all kinds of libraries to interact with regexps without hassles. What if the unquoted regex were treated exactly the same as bit justAnotherRegex(in char[] s, inout int pos, out char[][] subStrings) { //implementation in D. } Then we could write ok = /lkajsdlkjaksdf/ (aDataLine, i, theDollars); with no problem. And, if we code responsibly and so Mother would be proud, we might make it a habit to write in the following style: enum {firstNam, lastNam} if ( /lkjslkjlskjdlksjdf/ (currentLine, where, S) ) { victim = S[lastNam] ~ " ," ~ S[firstNam]; } Also, if a bare regular expression is considered an anonymous function, then it could be passed around with Delegates, Function Pointers, and Dynamic Closures.
Feb 16 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
Matthew wrote:
 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. :-)

Man, I'm proud of D !!!!!!!!! Thanks, Walter, for such a wonderful language! And thanks, Matthew, for bringing up the regexp issue! Think about it, it's only two days since then, and already we have figured out how to smoothly incorporate regexps into D! Both syntax wise, and (I guess, and hope) also smoothly for Walter, who has to do the hard work. As the regexp issue stands now, I see awesome power in it. If this doesn't take us way higher than #29, I'll eat quiche for a month! --------- You know, today I had a business meeting. I got there late, and couldn't even bring myself to the issues at hand. All I went on about was how we now have regexps in D, and how easy it was -- all it took was a bit of serious thinking. Some of the audience actually got excited. :-) There is something right in D!
Feb 16 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Georg Wrede wrote:
 Matthew wrote:
 
 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. :-)

Man, I'm proud of D !!!!!!!!! Thanks, Walter, for such a wonderful language! And thanks, Matthew, for bringing up the regexp issue! Think about it, it's only two days since then, and already we have figured out how to smoothly incorporate regexps into D! Both syntax wise, and (I guess, and hope) also smoothly for Walter, who has to do the hard work. As the regexp issue stands now, I see awesome power in it. If this doesn't take us way higher than #29, I'll eat quiche for a month! --------- You know, today I had a business meeting. I got there late, and couldn't even bring myself to the issues at hand. All I went on about was how we now have regexps in D, and how easy it was -- all it took was a bit of serious thinking. Some of the audience actually got excited. :-) There is something right in D!

I would be excited too but... Did I miss a post? Did Walter endorse the idea already or say he was in the works of implementing it in D? Otherwise, we can't celebrate yet! :-P
Feb 16 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
John Reimer wrote:
 Did I miss a post?  Did Walter endorse the idea 
 already or say he was in the works of implementing
 it in D?
 
 Otherwise, we can't celebrate yet! :-P

Hmm. You're right! However, even if he doesn't, I'm still going to raise a glass of champagne this Friday for D! Merely being able to figure out a smooth way to do it, is something a bunch of other languages don't offer!! :-P
Feb 16 2005
parent John Reimer <brk_6502 yahoo.com> writes:
On Thu, 17 Feb 2005 00:26:12 +0200, Georg Wrede wrote:

 
 
 John Reimer wrote:
 Did I miss a post?  Did Walter endorse the idea 

> it in D?
 
 Otherwise, we can't celebrate yet! :-P

Hmm. You're right! However, even if he doesn't, I'm still going to raise a glass of champagne this Friday for D! Merely being able to figure out a smooth way to do it, is something a bunch of other languages don't offer!! :-P

He he... true. Never hurts to be merry about such things. :-)
Feb 16 2005
prev sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <cuo83m$1mjn$1 digitaldaemon.com>, Walter says...
http://www.tiobe.com/tpci.htm

We've risen to number 29!

Doesn't anyone else find strange that D is higher then objective-C? Ant
Feb 16 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:cuvje9$77s$1 digitaldaemon.com...
 In article <cuo83m$1mjn$1 digitaldaemon.com>, Walter says...
http://www.tiobe.com/tpci.htm

We've risen to number 29!

Doesn't anyone else find strange that D is higher then objective-C?

Not me. Back in the ancient times, when dinosaurs and C ruled, I was looking for a way to set my C compiler (Datalight C) apart from the crowd. I ran across Objective-C by Stepstone and C++ by AT&T. Both were used about equally, and there was fierce debate about which one was going to be the future. But Stepstone wanted royalties for anyone wanting to do Objective-C. I contacted AT&T, and they graciously said I could implement a C++ compiler, call it C++, and not pay royalties to AT&T. (They also thanked me for being the only one who ever bothered to even ask!) That settled it for me, C++ was the future.
Feb 16 2005
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:cv0otb$1lmn$1 digitaldaemon.com...
 "Ant" <Ant_member pathlink.com> wrote in message
 news:cuvje9$77s$1 digitaldaemon.com...
 In article <cuo83m$1mjn$1 digitaldaemon.com>, Walter says...
http://www.tiobe.com/tpci.htm

We've risen to number 29!

Doesn't anyone else find strange that D is higher then objective-C?

Not me. Back in the ancient times, when dinosaurs and C ruled, I was looking for a way to set my C compiler (Datalight C) apart from the crowd. I ran across Objective-C by Stepstone and C++ by AT&T. Both were used about equally, and there was fierce debate about which one was going to be the future. But Stepstone wanted royalties for anyone wanting to do Objective-C. I contacted AT&T, and they graciously said I could implement a C++ compiler, call it C++, and not pay royalties to AT&T. (They also thanked me for being the only one who ever bothered to even ask!) That settled it for me, C++ was the future.

LOL! Just think what might have been. :-)
Feb 16 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cv0pqj$1mp1$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cv0otb$1lmn$1 digitaldaemon.com...
 But Stepstone wanted royalties for anyone wanting to do Objective-C. I
 contacted AT&T, and they graciously said I could implement a C++
 compiler,
 call it C++, and not pay royalties to AT&T. (They also thanked me for
 being
 the only one who ever bothered to even ask!)

 That settled it for me, C++ was the future.

LOL! Just think what might have been. :-)

Zortech's C++ compiler came out at just the nick of time to generate critical mass for C++. Before ZTC++, programming in C++ on the PC wasn't very practical (cfront just didn't adapt well to memory models, was expensive, didn't mesh well with PC C backends, and was very slow). ZTC++ opened up the PC programming market for C++, and that was a critical factor in the adoption of C++ by the programming industry. ZTC++'s success pretty much terminated the development interest of major compiler vendors in other OOP languages or their own proprietary OOP languages. Ever wonder why COM's vtable layout matches ZTC++'s ? <g>
Feb 16 2005
next sibling parent John Reimer <brk_6502 yahoo.com> writes:
Walter wrote:
 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 news:cv0pqj$1mp1$1 digitaldaemon.com...
 
"Walter" <newshound digitalmars.com> wrote in message
news:cv0otb$1lmn$1 digitaldaemon.com...

But Stepstone wanted royalties for anyone wanting to do Objective-C. I
contacted AT&T, and they graciously said I could implement a C++
compiler,
call it C++, and not pay royalties to AT&T. (They also thanked me for
being
the only one who ever bothered to even ask!)

That settled it for me, C++ was the future.

LOL! Just think what might have been. :-)

Zortech's C++ compiler came out at just the nick of time to generate critical mass for C++. Before ZTC++, programming in C++ on the PC wasn't very practical (cfront just didn't adapt well to memory models, was expensive, didn't mesh well with PC C backends, and was very slow). ZTC++ opened up the PC programming market for C++, and that was a critical factor in the adoption of C++ by the programming industry. ZTC++'s success pretty much terminated the development interest of major compiler vendors in other OOP languages or their own proprietary OOP languages. Ever wonder why COM's vtable layout matches ZTC++'s ? <g>

The Zortech C++ compiler was what I learned C++ on (well.. the C++ back then was not near as complicated as it is now) during my highschool days. The "demo" compiler came with a book I had mail-order purchased. I don't remember what the name of the book is now, though. - John R.
Feb 16 2005
prev sibling parent Kris <Kris_member pathlink.com> writes:
In article <cv0tej$1q2v$1 digitaldaemon.com>, Walter says...
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:cv0pqj$1mp1$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote in message
 news:cv0otb$1lmn$1 digitaldaemon.com...
 But Stepstone wanted royalties for anyone wanting to do Objective-C. I
 contacted AT&T, and they graciously said I could implement a C++
 compiler,
 call it C++, and not pay royalties to AT&T. (They also thanked me for
 being
 the only one who ever bothered to even ask!)

 That settled it for me, C++ was the future.

LOL! Just think what might have been. :-)

Zortech's C++ compiler came out at just the nick of time to generate critical mass for C++. Before ZTC++, programming in C++ on the PC wasn't very practical (cfront just didn't adapt well to memory models, was expensive, didn't mesh well with PC C backends, and was very slow). ZTC++ opened up the PC programming market for C++, and that was a critical factor in the adoption of C++ by the programming industry. ZTC++'s success pretty much terminated the development interest of major compiler vendors in other OOP languages or their own proprietary OOP languages.

Ahh, so we can blame you then. Are you trying to make amends with D? :-)
Feb 16 2005