Jarrett Billingsley wrote:
> "pragma" <pragma_member@pathlink.com> wrote in message news:d15jro$4e1$1@digitaldaemon.com...
> 
>>The thumbnail sketch of a regexp is basically the world's most compact parser
>>languge.  It makes relatively sizable parsing chores a breeze, by offloading all
>>the messy details to a common syntax and a runtime engine to support it.
> 
> Oh, well then.  I suppose they might be useful when writing something like a source analyzer tool, or anything else that parses text.

Right. And that's exactly what I'm doing with the meta thing right now.

Also, whenever you make a program that takes a text file as its input, regexps are more flexible than the functions in std.string.

find, cmp, ifind, inPattern, inPatterns

are all useful and handy for what they do, but they are most useful in "simple" situations.

>>All things said and done, I don't use regexps very often.  However, they come in
>>*very handy* when I want a quick solution to a parsing problem, or simply don't
>>mind trading runtime performance for sane-looking code.
> 
> I can see what you mean.  I'm not sure why they'd need to be part of the language, as they are useful, but not _that_ integral. 

True, this time I was talking about having some of the most useful in the standard library. Not in the language itself.

Incidentally, unfamiliarity with regexps is yet another reason why one should install Linux and use it. Familiarity with Linux is increasingly becoming a must for anybody who even remotely considers computers or programming as a future career (or even serious hobby).

And that brings regexps sort of "easily and naturally" into your life. You'll hardly even notice.

Derek Parnell wrote:
> On Mon, 14 Mar 2005 21:31:34 -0500, Jarrett Billingsley wrote:
>>"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4235751B.5020009@nospam.org...
>>
>>>Hands up?
>>>Stuff like
>>> - find next number
>>> - find next float
>>> - find next identifier
>>> - find next URL
>>> - find next filename (one for windows, unix, etc.)
>>> - find next _valid_ http tag
>>> - find next regexp
>>>This would save a lot of time when coding.
>>>Why invent the wheel over and over! ??
>>
> They are very handy for applications that do a *lot* of text processing,
> but I don't think that they warrant being built-in to the language. Library

Right. (So this was totally separate from the thread a few weeks ago about Unquoted Regular Expressions in D.)

> routines ought to suffice. In fact, I'm sure that if they were built-in,
> they would only be syntax sweeteners for library calls anyway. That is, the
> dmd compiler would insert a call to a library routine to perform the

I was thinking of having some stock functions in the library.

> requested functionality. Ok, with regexp literals it would do this at
> compile time rather than at run time, but that is not going to be a
> world-beating performance improvement.
> 
> I suspect an interface into the PCRE library ( http://www.pcre.org/ ) will
> suit nearly all needs in this area.

Hmm, took a look at it. Will look some more, hopefully there would be something useful to get into the D library too.

In article <d15lj4$5rt$1@digitaldaemon.com>, Jarrett Billingsley says...
>
>I can see what you mean.  I'm not sure why they'd need to be part of the language, as they are useful, but not _that_ integral.
>

There are a couple different reasons why one would build regular-expressions into a compiled language.  IMO, its past the point of diminishing returns, and aside from D's stated goals.

If a given regular expression were compiled into native code, it would obviously be faster than its runtime counterpart.  That alone could make building high-performance parsing applications easier.  However, this would require an additional parse/lex/compile unit to be added onto the D compiler; this is not as trivial a task as some would believe.

Another angle is "evangelizing" users of other languages to D on the grounds that D "eats perl's lunch" when it comes to text processing.  Perl has the advantage in that regexps are a "built-in" feature of the language syntax. Bringing D up to that standard of use for parsing would go a long way to enticing folks used to programming like this.

IMO, D is a hammer and perl is a screwdriver: D can be used to do perl's job, but that's for folks who like pounding screws all afternoon.

- EricAnderton at yahoo

I'm not sure what this is about, but if you have some standard regexps you want, such as find next http tag, a hand-built version is much faster than writing it in generic regexp'isms.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:4235751B.5020009@nospam.org...
> Hands up?
>
> I do too.
>
> What if we collected the most used and needed regexps? They could be precompiled, and maybe put as part of Phobos?
>
> Stuff like
>
>  - find next number
>  - find next float
>  - find next identifier
>  - find next URL
>  - find next filename (one for windows, unix, etc.)
>  - find next _valid_ http tag
>  - find next regexp
>
>
> The last one would be cool. While I could never write one, I bet there is one on the internet somewhere!!
>
> What other regexps would be nice? Those that are harder to write would be most valuable, I think.
>
> This would save a lot of time when coding.
>
> Why invent the wheel over and over! ??