www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 0.148 - regular expressions

reply "Walter Bright" <newshound digitalmars.com> writes:
The match expressions are gone. Based on the feedback, people didn't want D 
to adopt perl'ish notation or implicitly defined variables. Instead, foreach 
statements now allow implicit typing of the key/value declarations, and the 
if statement now can declare a variable for the result (an adaptation of Ben 
Hinkle's idea).
Feb 25 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2006-02-26:

 Instead, foreach statements now allow implicit typing of the key/value
declarations


[snip]

The only missing implicit typing:






<g>

Thomas

-----BEGIN PGP SIGNATURE-----

iD8DBQFEAXyk3w+/yD4P9tIRAlmMAKDOAaV/R2cXBx8stfaO5Hw86tgPsQCgpAbu
HeEgU5DtCYRndFs/FGVFgZw=
=57jc
-----END PGP SIGNATURE-----
Feb 26 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
That looks absolutely amazing.  I want.

-[Unknown]



 Walter Bright schrieb am 2006-02-26:

 Instead, foreach statements now allow implicit typing of the key/value
declarations


 [snip]
 
 The only missing implicit typing:
 




 
 <g>
 
 Thomas
Feb 26 2006
parent James Dunne <james.jdunne gmail.com> writes:
Unknown W. Brackets wrote:

 That looks absolutely amazing.  I want.
 
 -[Unknown]
 
 

 Walter Bright schrieb am 2006-02-26:


 Instead, foreach statements now allow implicit typing of the 
 key/value declarations


 [snip]

 The only missing implicit typing:






 <g>

 Thomas




OMG, teh ambiguity! =P

Anyway, you really can't do this at the moment?  Oh well, probably 
because auto parameters don't exist yet (AFAIK).

-- 
Regards,
James Dunne
Feb 26 2006
prev sibling next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:


 The match expressions are gone. Based on the feedback, people didn't want
 D to adopt perl'ish notation or implicitly defined variables. Instead,
 foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).


I liked the idea (match expressions), just not the operator, and I thought
that was a common opinion...
Feb 26 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Lars Ivar Igesund wrote:

 Walter Bright wrote:
 
 

The match expressions are gone. Based on the feedback, people didn't want
D to adopt perl'ish notation or implicitly defined variables. Instead,
foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).


 
 
 I liked the idea (match expressions), just not the operator, and I thought
 that was a common opinion...


Me too (except I even liked the operator) :)
Feb 26 2006
parent reply Tom <Tom_member pathlink.com> writes:
In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...

Lars Ivar Igesund wrote:

 Walter Bright wrote:
 
 

The match expressions are gone. Based on the feedback, people didn't want
D to adopt perl'ish notation or implicitly defined variables. Instead,
foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).


 
 
 I liked the idea (match expressions), just not the operator, and I thought
 that was a common opinion...


Me too (except I even liked the operator) :)


There was a common opinion but on the opposed. I felt the same as Walter about
match expressions in the NG. 

My own thought about match expressions is that they introduce TOO MUCH lib
functionality (common only for certain types of apps), making D *very*
overloaded (think about future writers of the compiler). The most of the people
felt that introducing match expressions really introduces NO NEW functionality.
Rather it just saves you the time of writing "import std.regexp;" (i guess). And
also they introduced more complexity than needed and new bugs to fix. Match
expressions was a luxury that D couldn't afford as D has many other
*really-prior-and-crucial* things to work out if it want's to become 1.0.

JMHO


Tom;
Feb 26 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Tom wrote:


 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...

Lars Ivar Igesund wrote:

 Walter Bright wrote:
 
 

The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).


 
 
 I liked the idea (match expressions), just not the operator, and I
 thought that was a common opinion...


Me too (except I even liked the operator) :)


 
 There was a common opinion but on the opposed. I felt the same as Walter
 about match expressions in the NG.
 
 My own thought about match expressions is that they introduce TOO MUCH lib
 functionality (common only for certain types of apps), making D *very*
 overloaded (think about future writers of the compiler). The most of the
 people felt that introducing match expressions really introduces NO NEW
 functionality. Rather it just saves you the time of writing "import
 std.regexp;" (i guess). And also they introduced more complexity than
 needed and new bugs to fix. Match expressions was a luxury that D couldn't
 afford as D has many other *really-prior-and-crucial* things to work out
 if it want's to become 1.0.
 
 JMHO
 
 
 Tom;


I think the "common opinion" was too coloured by the fact that we didn't
really expect it to go away (but maybe change), thus many of those having
positive feelings toward the match expressions didn't voice their opinion
at all (at least I didn't). But I guess a vote would give a 50/50 result :)
Feb 26 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Lars Ivar Igesund wrote:

 Tom wrote:
 

 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...

 Lars Ivar Igesund wrote:

 Walter Bright wrote:



 The match expressions are gone. Based on the feedback, people didn't
 want D to adopt perl'ish notation or implicitly defined variables.
 Instead, foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).


 I liked the idea (match expressions), just not the operator, and I
 thought that was a common opinion...


 Me too (except I even liked the operator) :)


 There was a common opinion but on the opposed. I felt the same as Walter
 about match expressions in the NG.

 My own thought about match expressions is that they introduce TOO MUCH lib
 functionality (common only for certain types of apps), making D *very*
 overloaded (think about future writers of the compiler). The most of the
 people felt that introducing match expressions really introduces NO NEW
 functionality. Rather it just saves you the time of writing "import
 std.regexp;" (i guess). And also they introduced more complexity than
 needed and new bugs to fix. Match expressions was a luxury that D couldn't
 afford as D has many other *really-prior-and-crucial* things to work out
 if it want's to become 1.0.

 JMHO


 Tom;


 
 I think the "common opinion" was too coloured by the fact that we didn't
 really expect it to go away (but maybe change), thus many of those having
 positive feelings toward the match expressions didn't voice their opinion
 at all (at least I didn't). But I guess a vote would give a 50/50 result :)


IMHO, match expressions are not a natural part of a language that claims to be
for systems programming.
Feb 26 2006
prev sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <dtse93$1fou$1 digitaldaemon.com>, Lars Ivar Igesund says...

Tom wrote:


 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...

Lars Ivar Igesund wrote:

 Walter Bright wrote:
 
 

The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).


 
 
 I liked the idea (match expressions), just not the operator, and I
 thought that was a common opinion...


Me too (except I even liked the operator) :)


 
 There was a common opinion but on the opposed. I felt the same as Walter
 about match expressions in the NG.
 
 My own thought about match expressions is that they introduce TOO MUCH lib
 functionality (common only for certain types of apps), making D *very*
 overloaded (think about future writers of the compiler). The most of the
 people felt that introducing match expressions really introduces NO NEW
 functionality. Rather it just saves you the time of writing "import
 std.regexp;" (i guess). And also they introduced more complexity than
 needed and new bugs to fix. Match expressions was a luxury that D couldn't
 afford as D has many other *really-prior-and-crucial* things to work out
 if it want's to become 1.0.
 
 JMHO
 
 
 Tom;


I think the "common opinion" was too coloured by the fact that we didn't
really expect it to go away (but maybe change), thus many of those having
positive feelings toward the match expressions didn't voice their opinion
at all (at least I didn't). But I guess a vote would give a 50/50 result :)


Maybe (don't think so) but we'll have to see it to believe it. ;-)

Tom;
Feb 26 2006
parent Dave <Dave_member pathlink.com> writes:
In article <dtsge2$1i5t$1 digitaldaemon.com>, Tom says...

In article <dtse93$1fou$1 digitaldaemon.com>, Lars Ivar Igesund says...

Tom wrote:


 In article <dts7qi$18b0$1 digitaldaemon.com>, Ivan Senji says...

Lars Ivar Igesund wrote:

 Walter Bright wrote:
 
 

The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).


 
 
 I liked the idea (match expressions), just not the operator, and I
 thought that was a common opinion...


Me too (except I even liked the operator) :)


 
 There was a common opinion but on the opposed. I felt the same as Walter
 about match expressions in the NG.
 
 My own thought about match expressions is that they introduce TOO MUCH lib
 functionality (common only for certain types of apps), making D *very*
 overloaded (think about future writers of the compiler). The most of the
 people felt that introducing match expressions really introduces NO NEW
 functionality. Rather it just saves you the time of writing "import
 std.regexp;" (i guess). And also they introduced more complexity than
 needed and new bugs to fix. Match expressions was a luxury that D couldn't
 afford as D has many other *really-prior-and-crucial* things to work out
 if it want's to become 1.0.
 
 JMHO
 
 
 Tom;


I think the "common opinion" was too coloured by the fact that we didn't
really expect it to go away (but maybe change), thus many of those having
positive feelings toward the match expressions didn't voice their opinion
at all (at least I didn't). But I guess a vote would give a 50/50 result :)


Maybe (don't think so) but we'll have to see it to believe it. ;-)

Tom;


IMHO, the vote would be about 70 - 30 for the built-in's, especially with the
addition of 'if statement result declarations' that would get rid of the
implicit variables.

Since AFAIK they don't complicate the compiler that much, they don't have any
overhead if they aren't used and don't prevent the direct use of a regex
library, I don't see any downside of making them built-in.

- Dave
Feb 26 2006
prev sibling next sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...

Walter Bright wrote:


 The match expressions are gone. Based on the feedback, people didn't want
 D to adopt perl'ish notation or implicitly defined variables. Instead,
 foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).


I liked the idea (match expressions), just not the operator, and I thought
that was a common opinion...


So did I (but the operators didn't bother me). I was surprised to see the
'built-in' behaviour removed. From my understanding, it wasn't terribly
complicated to implement and there wasn't any overhead unless it was used. There
really wasn't any 'perl'ish notation' to speak of, and the recent addition of if
statement result variables would have taken care of the implicitly defined
variable issue.

I think it was a mistake to remove the built-in's. Now I bet they're gone for
good. Arrrgh. I think D would better appeal to a large segment of developers
(using scripting languages like Perl) with the built-in regex match
functionality. 

IIRC, most of the posts liked the built-in idea but took issue with a few of the
details. We've gone from talk about how the compiler can optimize matching
behaviour to removing the built-in's entirely. I don't get it..

- Dave
Feb 26 2006
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
In article <dtsjs6$1lp0$1 digitaldaemon.com>, Dave says...

In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...

Walter Bright wrote:


 The match expressions are gone. Based on the feedback, people didn't want
 D to adopt perl'ish notation or implicitly defined variables. Instead,
 foreach statements now allow implicit typing of the key/value
 declarations, and the if statement now can declare a variable for the
 result (an adaptation of Ben Hinkle's idea).


I liked the idea (match expressions), just not the operator, and I thought
that was a common opinion...


So did I (but the operators didn't bother me). I was surprised to see the
'built-in' behaviour removed. From my understanding, it wasn't terribly
complicated to implement and there wasn't any overhead unless it was used. There
really wasn't any 'perl'ish notation' to speak of, and the recent addition of if
statement result variables would have taken care of the implicitly defined
variable issue.

I think it was a mistake to remove the built-in's. Now I bet they're gone for
good. Arrrgh. I think D would better appeal to a large segment of developers
(using scripting languages like Perl) with the built-in regex match
functionality. 

IIRC, most of the posts liked the built-in idea but took issue with a few of the
details. We've gone from talk about how the compiler can optimize matching
behaviour to removing the built-in's entirely. I don't get it..

- Dave


I think the addition and than removal was pretty odd.. I was just about to
rewrite some code using the match operator - but I am glad I diddn't.

But you know - as much as we all demand features and get mad when they aren't
included, it was nice to see a feature get included. But now it gets taken away
so quickly, I don't know what will be taken out next.. :)

Please don't remove dynamic arrays walter!

Just kidding - we all love you!

Thanks,
Trevor Parscal
Feb 26 2006
next sibling parent reply James Dunne <james.jdunne gmail.com> writes:
Trevor Parscal wrote:

 In article <dtsjs6$1lp0$1 digitaldaemon.com>, Dave says...
 

In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...


Walter Bright wrote:



The match expressions are gone. Based on the feedback, people didn't want
D to adopt perl'ish notation or implicitly defined variables. Instead,
foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).


I liked the idea (match expressions), just not the operator, and I thought
that was a common opinion...


So did I (but the operators didn't bother me). I was surprised to see the
'built-in' behaviour removed. From my understanding, it wasn't terribly
complicated to implement and there wasn't any overhead unless it was used. There
really wasn't any 'perl'ish notation' to speak of, and the recent addition of if
statement result variables would have taken care of the implicitly defined
variable issue.

I think it was a mistake to remove the built-in's. Now I bet they're gone for
good. Arrrgh. I think D would better appeal to a large segment of developers
(using scripting languages like Perl) with the built-in regex match
functionality. 

IIRC, most of the posts liked the built-in idea but took issue with a few of the
details. We've gone from talk about how the compiler can optimize matching
behaviour to removing the built-in's entirely. I don't get it..

- Dave


 
 
 I think the addition and than removal was pretty odd.. I was just about to
 rewrite some code using the match operator - but I am glad I diddn't.
 
 But you know - as much as we all demand features and get mad when they aren't
 included, it was nice to see a feature get included. But now it gets taken away
 so quickly, I don't know what will be taken out next.. :)
 
 Please don't remove dynamic arrays walter!
 
 Just kidding - we all love you!
 
 Thanks,
 Trevor Parscal


Why is this move (taking out the built-in behavior) so seemingly 
unexpected to everyone?  Walter outright said "Don't write production 
code with this feature."

-- 
Regards,
James Dunne
Feb 26 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
James Dunne wrote:


 Trevor Parscal wrote:

 In article <dtsjs6$1lp0$1 digitaldaemon.com>, Dave says...
 

In article <dts47r$14c0$1 digitaldaemon.com>, Lars Ivar Igesund says...


Walter Bright wrote:



The match expressions are gone. Based on the feedback, people didn't
want D to adopt perl'ish notation or implicitly defined variables.
Instead, foreach statements now allow implicit typing of the key/value
declarations, and the if statement now can declare a variable for the
result (an adaptation of Ben Hinkle's idea).


I liked the idea (match expressions), just not the operator, and I
thought that was a common opinion...


So did I (but the operators didn't bother me). I was surprised to see the
'built-in' behaviour removed. From my understanding, it wasn't terribly
complicated to implement and there wasn't any overhead unless it was
used. There really wasn't any 'perl'ish notation' to speak of, and the
recent addition of if statement result variables would have taken care of
the implicitly defined variable issue.

I think it was a mistake to remove the built-in's. Now I bet they're gone
for good. Arrrgh. I think D would better appeal to a large segment of
developers (using scripting languages like Perl) with the built-in regex
match functionality.

IIRC, most of the posts liked the built-in idea but took issue with a few
of the details. We've gone from talk about how the compiler can optimize
matching behaviour to removing the built-in's entirely. I don't get it..

- Dave


 
 
 I think the addition and than removal was pretty odd.. I was just about
 to rewrite some code using the match operator - but I am glad I diddn't.
 
 But you know - as much as we all demand features and get mad when they
 aren't included, it was nice to see a feature get included. But now it
 gets taken away so quickly, I don't know what will be taken out next.. :)
 
 Please don't remove dynamic arrays walter!
 
 Just kidding - we all love you!
 
 Thanks,
 Trevor Parscal


 
 Why is this move (taking out the built-in behavior) so seemingly
 unexpected to everyone?  Walter outright said "Don't write production
 code with this feature."
 


You are of course correct in this, but it in my (quite so erratic at times)
mind, this meant that the syntax probably would be changed, not removed
altoghether. Also, I don't really think the D as Script feature makes much
sense without some additional regexy sugar, even if it is still quite
usable of course.
Feb 26 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:dtso8j$1r01$1 digitaldaemon.com...

 You are of course correct in this, but it in my (quite so erratic at 
 times)
 mind, this meant that the syntax probably would be changed, not removed
 altoghether. Also, I don't really think the D as Script feature makes much
 sense without some additional regexy sugar, even if it is still quite
 usable of course.


It's still there in the form:

    if (m; search("string", "pattern"))
        ... do something with m.match(0) ...

as opposed to:

    if ("pattern" ~~ "search")
        ... do something with _match.match(0) ...

There isn't much sugar to the latter over the former, and it has the 
disadvantage of implicit declarations, which in general are a bad idea.
Feb 26 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:dtsl91$1ncs$1 digitaldaemon.com...

 I think the addition and than removal was pretty odd.. I was just about to
 rewrite some code using the match operator - but I am glad I diddn't.

 But you know - as much as we all demand features and get mad when they 
 aren't
 included, it was nice to see a feature get included. But now it gets taken 
 away
 so quickly, I don't know what will be taken out next.. :)


I wouldn't have removed it, but adding the declarations to the if statement, 
and the implicit typing to the foreach, made the match expression's 
incremental convenience pretty minor. Lest D become a bag of cruft, new 
operators need to offer a *big* improvement in convenience.


 Please don't remove dynamic arrays walter!


Fat chance of that!
Feb 26 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
news:dts47r$14c0$1 digitaldaemon.com...

 I liked the idea (match expressions), just not the operator, and I thought
 that was a common opinion...


if ("regex" ~~ "string")
    _match. ...

The equivalent functionality can now be done with:

if (m; search("string", "regex"))
    m. ...
Feb 26 2006
next sibling parent reply Johan Granberg <lijat.meREM OVEgmail.com> writes:
Walter Bright wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message 
 news:dts47r$14c0$1 digitaldaemon.com...

 I liked the idea (match expressions), just not the operator, and I thought
 that was a common opinion...


 
 if ("regex" ~~ "string")
     _match. ...
 
 The equivalent functionality can now be done with:
 
 if (m; search("string", "regex"))
     m. ...
 


Why not do like this instead?

if (m;"regex" ~~ "string")
	m. ...

That would get rid of the implicit declaration of _match and just like 
usual with statements the result of ~~ could bee ignored.
Feb 26 2006
parent "Walter Bright" <newshound digitalmars.com> writes:
"Johan Granberg" <lijat.meREM OVEgmail.com> wrote in message 
news:dtsu0h$21ct$1 digitaldaemon.com...

 Why not do like this instead?

 if (m;"regex" ~~ "string")
 m. ...

 That would get rid of the implicit declaration of _match and just like 
 usual with statements the result of ~~ could bee ignored.


Because it doesn't offer enough utility over the function version to justify 
it.
Feb 26 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright  
<newshound digitalmars.com> wrote:


 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...

 I liked the idea (match expressions), just not the operator, and I  
 thought
 that was a common opinion...


 if ("regex" ~~ "string")
     _match. ...

 The equivalent functionality can now be done with:

 if (m; search("string", "regex"))
     m. ...


I don't think that is quite correct. This program failed to compile ....

   void main()
   {
     if (m; search("string", "regex")) {}
   }


I got the messages ...
   test2.d(3): undefined identifier search
   test2.d(3): function expected before (), not search of type int

It turns out that "import std.regexp;" is now required.

-- 
Derek Parnell
Melbourne, Australia
Feb 26 2006
next sibling parent reply Tom <Tom_member pathlink.com> writes:
In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...

On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright  
<newshound digitalmars.com> wrote:


 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...

 I liked the idea (match expressions), just not the operator, and I  
 thought
 that was a common opinion...


 if ("regex" ~~ "string")
     _match. ...

 The equivalent functionality can now be done with:

 if (m; search("string", "regex"))
     m. ...


I don't think that is quite correct. This program failed to compile ....

   void main()
   {
     if (m; search("string", "regex")) {}
   }


I got the messages ...
   test2.d(3): undefined identifier search
   test2.d(3): function expected before (), not search of type int

It turns out that "import std.regexp;" is now required.


This was pretty obvious IMO, don't you think so? :) I mean, if the feature was
removed, of course, you would require 'std.regexp' imported again. I think
Walter omitted it because of that.

Tom;
Feb 26 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 27 Feb 2006 06:46:41 +1100, Tom <Tom_member pathlink.com> wrote:


 In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell  
 says...

 On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright
 <newshound digitalmars.com> wrote:


 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...

 I liked the idea (match expressions), just not the operator, and I
 thought
 that was a common opinion...


 if ("regex" ~~ "string")
     _match. ...

 The equivalent functionality can now be done with:

 if (m; search("string", "regex"))
     m. ...


 I don't think that is quite correct. This program failed to compile ....

   void main()
   {
     if (m; search("string", "regex")) {}
   }


 I got the messages ...
   test2.d(3): undefined identifier search
   test2.d(3): function expected before (), not search of type int

 It turns out that "import std.regexp;" is now required.


 This was pretty obvious IMO, don't you think so? :) I mean, if the  
 feature was
 removed, of course, you would require 'std.regexp' imported again. I  
 think
 Walter omitted it because of that.


Of course it was obvious; that was my point.

Walter had written that
   "if ("regex" ~~ "string")"
was functionally equivalent to
   "if (m; search("string", "regex"))"
and while that is true, it gives the impression that this was the *only*  
change to the new D. I just wanted to point out that the implicit  
importing of std.regexp was also removed.

-- 
Derek Parnell
Melbourne, Australia
Feb 26 2006
parent Tom <Tom_member pathlink.com> writes:
In article <op.s5lmdqep6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...

On Mon, 27 Feb 2006 06:46:41 +1100, Tom <Tom_member pathlink.com> wrote:


 In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell  
 says...

 On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright
 <newshound digitalmars.com> wrote:


 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...

 I liked the idea (match expressions), just not the operator, and I
 thought
 that was a common opinion...


 if ("regex" ~~ "string")
     _match. ...

 The equivalent functionality can now be done with:

 if (m; search("string", "regex"))
     m. ...


 I don't think that is quite correct. This program failed to compile ....

   void main()
   {
     if (m; search("string", "regex")) {}
   }


 I got the messages ...
   test2.d(3): undefined identifier search
   test2.d(3): function expected before (), not search of type int

 It turns out that "import std.regexp;" is now required.


 This was pretty obvious IMO, don't you think so? :) I mean, if the  
 feature was
 removed, of course, you would require 'std.regexp' imported again. I  
 think
 Walter omitted it because of that.


Of course it was obvious; that was my point.

Walter had written that
   "if ("regex" ~~ "string")"
was functionally equivalent to
   "if (m; search("string", "regex"))"
and while that is true, it gives the impression that this was the *only*  
change to the new D. I just wanted to point out that the implicit  
importing of std.regexp was also removed.


Ok, I forgive you :) :P
Now seriously, I see your point.

Regards,

Tom;
Feb 26 2006
prev sibling next sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au...

 It turns out that "import std.regexp;" is now required.


That's right.
Feb 26 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
In article <op.s5lhaxyb6b8z09 ginger.vic.bigpond.net.au>, Derek Parnell says...

On Mon, 27 Feb 2006 04:58:21 +1100, Walter Bright  
<newshound digitalmars.com> wrote:


 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:dts47r$14c0$1 digitaldaemon.com...

 I liked the idea (match expressions), just not the operator, and I  
 thought
 that was a common opinion...


 if ("regex" ~~ "string")
     _match. ...

 The equivalent functionality can now be done with:

 if (m; search("string", "regex"))
     m. ...


I don't think that is quite correct. This program failed to compile ....

   void main()
   {
     if (m; search("string", "regex")) {}
   }


I got the messages ...
   test2.d(3): undefined identifier search
   test2.d(3): function expected before (), not search of type int

It turns out that "import std.regexp;" is now required.

-- 
Derek Parnell
Melbourne, Australia


Maybe a good compromise would be to use a built-in "proxy" for search() and
RegExp (along the same lines as '~~' was originally implemented)? Then there
would be no "perl'ish" syntax, no added operators, no overhead and the same
convenience to doing regex matching.

One problem I see with the new v0.148 regex stuff is that different search
functions (and syntax for them) are used for if() and foreach(), and they aren't
interchangable.

That's going to be confusing for newbies and feels kludgy to me - can't the two
functions be combined somehow?

- Dave
Feb 26 2006
prev sibling next sibling parent reply "Lionello Lunesu" <lio remove.lunesu.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:dtr2ff$2vqr$3 digitaldaemon.com...

 The match expressions are gone. Based on the feedback, people didn't want 
 D to adopt perl'ish notation or implicitly defined variables. Instead, 
 foreach statements now allow implicit typing of the key/value 
 declarations, and the if statement now can declare a variable for the 
 result (an adaptation of Ben Hinkle's idea).


Too bad you didn't create a separate thread for the new if statement. What 
was wrong with the C++ construction:

if (int a = getSome()) {...}

?

L.
Feb 27 2006
parent "Lionello Lunesu" <lio remove.lunesu.com> writes:
 Too bad you didn't create a separate thread for the new if statement. What 
 was wrong with the C++ construction:


Nevermind. I've found the thread already...
Feb 27 2006
prev sibling parent reply Dave <Dave_member pathlink.com> writes:
In article <dtr2ff$2vqr$3 digitaldaemon.com>, Walter Bright says...

if statement now can declare a variable for the result (an adaptation of Ben 
Hinkle's idea). 


I haven't seen this brought up yet, so if it has my apologies.

The if(valptr; (key in AA)) syntax also nicely improves on how 'in' is used to
avoid double lookups IMO. Still uses a pointer, but it is alot better.

old way:

int* p = (key in AA);
if(p) (*p)++;
else AA[key] = 1;

new:

if(p; key in AA) (*p)++;
else AA[key] = 1;

- Dave
Mar 02 2006
parent reply Chris Sauls <ibisbasenji gmail.com> writes:
Dave wrote:

 In article <dtr2ff$2vqr$3 digitaldaemon.com>, Walter Bright says...
 

if statement now can declare a variable for the result (an adaptation of Ben 
Hinkle's idea). 


 I haven't seen this brought up yet, so if it has my apologies.
 
 The if(valptr; (key in AA)) syntax also nicely improves on how 'in' is used to
 avoid double lookups IMO. Still uses a pointer, but it is alot better.
 
 old way:
 
 int* p = (key in AA);
 if(p) (*p)++;
 else AA[key] = 1;
 
 new:
 
 if(p; key in AA) (*p)++;
 else AA[key] = 1;
 
 - Dave


I hadn't even thought of that yet...  and I love it!  A server project of mine
uses the 
'in' operator quite a bit, and I've always been annoyed with predeclaring
variables and 
whatnot.  Now I won't have that issue, so long as Walter does the Right Thing
(TM) and 
leaves this in.

-- Chris Nicholson-Sauls
Mar 02 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Chris Sauls" <ibisbasenji gmail.com> wrote in message 
news:du8kgk$tem$1 digitaldaemon.com...

 I hadn't even thought of that yet...  and I love it!  A server project of 
 mine uses the 'in' operator quite a bit, and I've always been annoyed with 
 predeclaring variables and whatnot.  Now I won't have that issue, so long 
 as Walter does the Right Thing (TM) and leaves this in.


It'll stay in, but it'll be in the form:

    if (auto p = key in AA)

as just about everyone seemed to prefer that syntax.
Mar 03 2006
parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 "Chris Sauls" <ibisbasenji gmail.com> wrote in message 
 news:du8kgk$tem$1 digitaldaemon.com...
 

I hadn't even thought of that yet...  and I love it!  A server project of 
mine uses the 'in' operator quite a bit, and I've always been annoyed with 
predeclaring variables and whatnot.  Now I won't have that issue, so long 
as Walter does the Right Thing (TM) and leaves this in.


 
 
 It'll stay in, but it'll be in the form:
 
     if (auto p = key in AA)
 
 as just about everyone seemed to prefer that syntax. 
 


Will this work:

if( auto a = something() && auto b = something())

a more general solution of declaring/initializing variables by parts of 
expressions?

(auto a1 = x*y-z) * (1 - (auto a2 = sin(x+y)))?

That would be a nice feature, but maybe too complicated and not that 
much used?
Mar 04 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
news:dubrop$118j$1 digitaldaemon.com...

 Will this work:

 if( auto a = something() && auto b = something())

 a more general solution of declaring/initializing variables by parts of 
 expressions?


No, it won't work. Embedding declarations inside expressions leads to all 
sorts of problems, not the least of which is what happens in this scenario:

    if (auto a = foo() || auto b = bar())
    {
            a + b;        // is b declared or not?
    }
Mar 06 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:

 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dubrop$118j$1 digitaldaemon.com...
 

Will this work:

if( auto a = something() && auto b = something())

a more general solution of declaring/initializing variables by parts of 
expressions?


 
 
 No, it won't work. Embedding declarations inside expressions leads to all 
 sorts of problems, not the least of which is what happens in this scenario:


OK, I get it.


 
     if (auto a = foo() || auto b = bar())
     {
             a + b;        // is b declared or not?
     }
Mar 06 2006
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On Mon, 6 Mar 2006, Walter Bright wrote:


 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message 
 news:dubrop$118j$1 digitaldaemon.com...

 Will this work:

 if( auto a = something() && auto b = something())

 a more general solution of declaring/initializing variables by parts of 
 expressions?


 
 No, it won't work. Embedding declarations inside expressions leads to all 
 sorts of problems, not the least of which is what happens in this scenario:
 
     if (auto a = foo() || auto b = bar())
     {
             a + b;        // is b declared or not?
     } 


Easy enough to define the behavior.  I'm not sure what an 
appropriate term is for variables declared like this, so insert 
something appropriate below.  Something like this would work reasonably 
well, probably:

   For all variables declared in an if expression, they will be default 
initialized if their initializing expression is not executed due to short 
circuit evaluation.

So..

    if (auto /* int */ res1 = someIntegerExpression() ||
        auto /* int */ res2 = someOtherIntegerExpression())
    {
        return res1 + res2;
    }

The results of that become well defined.  What would be potentially 
problematic is if return types are ever added to function overloading / 
resolution.  But I won't get into my opinions on that or on implicit 
typing as it's ornthogonal to this topic.

Later,
Brad
Mar 06 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
Brad Roberts wrote:

 
    For all variables declared in an if expression, they will be default 
 initialized if their initializing expression is not executed due to short 
 circuit evaluation.


I had the same thought.  But how much value is there in offering this 
feature?  Since D defaults to trap values when possible, the user should 
typically check all values that may have been default initialized before 
using them, and this seems to reduce the utility of this syntax.  Though 
I suppose this doesn't change the fact that there is a simple, valid 
solution to the problem, which is the point you were trying to make.


Sean
Mar 06 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Brad Roberts" <braddr puremagic.com> wrote in message 
news:Pine.LNX.4.64.0603061143490.30259 bellevue.puremagic.com...

 Easy enough to define the behavior.


I know. But if there isn't an obvious and intuitive behavior to define, then 
one is picking something arbitrary. For example, the classic conundrum is:

    "12" + 6

Does that evaluate to "126" or 18? One can easilly define the behavior, but 
which one, and what will programmers expect it to be? With that expression, 
there really are only wrong answers, and so the only solution is to make it 
illegal.

For:

if (auto a = foo() || auto b = bar())
{
            a + b;        // is b declared or not?
 }

one could as sensibly define that b is only valid in the conditional 
subexpression in which it appears, as in:

if (auto a = foo() || (auto b = bar(), b + 1))    // ok, b valid in the b+1 
expression
{
        a + b;  // error, b undefined here
}

Faced with two equally valid but incompatible definitions, I think the best 
course of action is to make it illegal, especially since there doesn't seem 
to be much utility in such a feature anyway.
Mar 08 2006