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 

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  

 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. 
 
 


Since basicaly all those are is "magic" global variables, it 
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.


 Since basicaly all those are is "magic" global variables, it 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.


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


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


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

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.

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.

 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 


  > 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


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