February 14, 2005
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...)
February 14, 2005
>     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.
February 14, 2005
"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.



February 14, 2005
>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.


February 14, 2005
"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?


February 14, 2005
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.
February 14, 2005
"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.


February 14, 2005
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!
February 15, 2005
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.
February 15, 2005
"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!