DMD 0.148 - regular expressions (page 3) - D Programming Language Discussion Forum

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

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

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: >> >> # template square(auto x) >> # { >> # auto square = x * x; >> # } >> >> <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

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

February 27, 2006

Re: DMD 0.148 - regular expressions

Posted by Tom
in reply to Derek Parnell

Permalink

Tom

Posted in reply to Derek Parnell

Permalink

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;

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

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

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

Forums