Walter Bright says...
>
>
>"Sean Kelly" <sean@f4.ca> wrote in message news:dt0fp5$23qb$1@digitaldaemon.com...
>> Awesome!  This will take some getting used to, but it promises to be of tremendous use.  Don't ask me why a built-in feature seems preferable to the same thing in library code, but it does :-p
>
>I don't really know why either. std.regexp has been in D since day 1, but it's been completely overlooked, and I regularly get comments about D not doing regular expressions. If this is what it takes, then so be it <g>.

Most of the programs that I've done with D use std.regexp, so I use it all the time.

Kris wrote:
> "Sean Kelly" <sean@f4.ca> wrote ...
>> Walter Bright wrote:
>>> "Derek Parnell" <derek@psych.ward> wrote in message news:fdfenjm7wj46.1xmq12pyjxp8c$.dlg@40tude.net...
>>>
>>>> BTW, one side effect of the new matching syntax is that you don't have to
>>>> explicitly import std.regexp.
>>> That was on purpose. It uses a proxy.
>> As cool as this is, I don't entirely like the prospect of cutting yet more ties between standard library components and runtime code.  My approach with Ares has been to separate the two, which until now has meant moving only std.utf into the DMD runtime.  Now it looks like std.regex will end up there as well (along with std.outbuffer perhaps). With the new language features, is there any reason to continue regex library support?  Just how much can't be done by the built-in syntax?
> 
> I agree. And it's hard to fathom what the sudden rush to get this is about. I listed a number of (IMO) serious issues on the main forum, so I'll add my support here that hooking RegExp (and all its various imports) into the compiler is just bad news *at this point in time*

I'm willing to let the new language feature mature in place.  And while I think it's unnecessary given that it can be done just as well in library code, there's something about making regex handling a first class citizen that increases its appeal.  However, though I can understand Walter's desire to leverage existing code, I think it's a terrible mistake to make language features rely on library code, even if the relationship is concealed.  I don't think this is an issue for D in general (since the language spec obviously doesn't require this) so much as DMD specifically however.  For example, the GC code currently imports std.thread to do various things.  Now let's say that the private implementation of std.thread changes, and the changes have an impact on inlinable functions.  If the GC code isn't rebuilt, and if it was compiled with the -inline option set, all hell could break loose.

More generally however, such ties make it very difficult for third party library writers to provide alternate standard library implementations to work with DMD (similar to STLPort or STLSoft for C++), because the compiler runtime must be rebuilt to operate with any new library used. And it's difficult to be certain just what low-level features the runtime may rely on without well-defined points of interaction.  This is something I'm completely unfamiliar with coming from a C/C++ background, and it makes me wonder if any other compiled languages are like this as well.

Personally, I would love it if more attention were paid to defining necessary library interaction in D.  This is probably the most significant thing I've done in Ares and is what I think gives Ares the most credibility as a replacement standard library.  And while I would love for Walter to assume control of the DMD runtime and GC portions, doing so would require some care (and discussion) given to how language features such as regex are implemented: does the runtime truly need to interact with the standard library?  If so, how?

Implicit UTF conversions during foreach seems a reasonable language feature as such code is relatively simple to implement, but regular expression processing is somewhat complicated.  Is this a language feature that may be ignored by compilers that target embedded processors, simply because of size/complexity?  Can I expect to see shoddy regex implementations in some compilers such that I'm inclined to use a library implementation anyway?  My real concern isn't D now so much as D five years from now--I like the language enough that I really want it to succeed :-)

> Let's just suppose for a minute that the regex-templates work out well. It seems to me that any built-in support for regex (within the D grammar) would be nothing more than a thin veneer over the template syntax (for regex-templates), to make it somewhat  more palatable for the masses? That may not come to pass, but it seems that we should at least wait until there's a bit of education and experience in this regard, rather than hurriedly tie the grammar to something which clearly has a number of fundamental problems. Again; what's the big rush here?

It makes an odd sort of sense that a language designed by a compiler writer should have built-in regex support.  And it seems like Walter has been thinking about this for a while, so I'm willing to see how it goes.  But as a library writer, the way that Walter implements these changes gives me fits ;-)


Sean

Sean Kelly wrote:
> Kris wrote:
> 
>> "Sean Kelly" <sean@f4.ca> wrote ...
>>
>>> Walter Bright wrote:
>>>
>>>> "Derek Parnell" <derek@psych.ward> wrote in message news:fdfenjm7wj46.1xmq12pyjxp8c$.dlg@40tude.net...
>>>>
>>>>> BTW, one side effect of the new matching syntax is that you don't have to
>>>>> explicitly import std.regexp.
>>>>
>>>> That was on purpose. It uses a proxy.
>>>
>>> As cool as this is, I don't entirely like the prospect of cutting yet more ties between standard library components and runtime code.  My approach with Ares has been to separate the two, which until now has meant moving only std.utf into the DMD runtime.  Now it looks like std.regex will end up there as well (along with std.outbuffer perhaps). With the new language features, is there any reason to continue regex library support?  Just how much can't be done by the built-in syntax?
>>
>>
>> I agree. And it's hard to fathom what the sudden rush to get this is about. I listed a number of (IMO) serious issues on the main forum, so I'll add my support here that hooking RegExp (and all its various imports) into the compiler is just bad news *at this point in time*
> 
> 
> I'm willing to let the new language feature mature in place.  And while I think it's unnecessary given that it can be done just as well in library code, there's something about making regex handling a first class citizen that increases its appeal.  However, though I can understand Walter's desire to leverage existing code, I think it's a terrible mistake to make language features rely on library code, even if the relationship is concealed.  I don't think this is an issue for D in general (since the language spec obviously doesn't require this) so much as DMD specifically however.  For example, the GC code currently imports std.thread to do various things.  Now let's say that the private implementation of std.thread changes, and the changes have an impact on inlinable functions.  If the GC code isn't rebuilt, and if it was compiled with the -inline option set, all hell could break loose.
> 
> More generally however, such ties make it very difficult for third party library writers to provide alternate standard library implementations to work with DMD (similar to STLPort or STLSoft for C++), because the compiler runtime must be rebuilt to operate with any new library used. And it's difficult to be certain just what low-level features the runtime may rely on without well-defined points of interaction.  This is something I'm completely unfamiliar with coming from a C/C++ background, and it makes me wonder if any other compiled languages are like this as well.
> 
> Personally, I would love it if more attention were paid to defining necessary library interaction in D.  This is probably the most significant thing I've done in Ares and is what I think gives Ares the most credibility as a replacement standard library.  And while I would love for Walter to assume control of the DMD runtime and GC portions, doing so would require some care (and discussion) given to how language features such as regex are implemented: does the runtime truly need to interact with the standard library?  If so, how?
> 
> Implicit UTF conversions during foreach seems a reasonable language feature as such code is relatively simple to implement, but regular expression processing is somewhat complicated.  Is this a language feature that may be ignored by compilers that target embedded processors, simply because of size/complexity?  Can I expect to see shoddy regex implementations in some compilers such that I'm inclined to use a library implementation anyway?  My real concern isn't D now so much as D five years from now--I like the language enough that I really want it to succeed :-)
> 
>> Let's just suppose for a minute that the regex-templates work out well. It seems to me that any built-in support for regex (within the D grammar) would be nothing more than a thin veneer over the template syntax (for regex-templates), to make it somewhat  more palatable for the masses? That may not come to pass, but it seems that we should at least wait until there's a bit of education and experience in this regard, rather than hurriedly tie the grammar to something which clearly has a number of fundamental problems. Again; what's the big rush here?
> 
> 
> It makes an odd sort of sense that a language designed by a compiler writer should have built-in regex support.  And it seems like Walter has been thinking about this for a while, so I'm willing to see how it goes.  But as a library writer, the way that Walter implements these changes gives me fits ;-)
> 
> 
> Sean

Amen.

I made an eerily similar post on the D forum.

Walter Bright wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dt2476$ii2$1@digitaldaemon.com...
>> Walter Bright wrote:
>>> Added match expressions.
>>>
>>> http://www.digitalmars.com/d/changelog.html
>> So this
>>
>>     int[] x, y;
>>     ...
>>     x=y~~42;
>>
>> won't work anymore....
> 
> That's right. Neither will:
> 
>     x = !~y;
> 
> It's in the same vein that:
> 
>     x = y/*p;
> 
> never worked, either. 

At least neither of those two is syntactically valid now.

Why are MatchExpression and NotMatchExpression separate nonterminals? Why not simply

MatchExpression:
	EqualExpression ~~ RelExpression
	EqualExpression !~ RelExpression

or even

EqualExpression:
	RelExpression
	EqualExpression == RelExpression
	EqualExpression != RelExpression
	EqualExpression is RelExpression
	EqualExpression !is RelExpression
	EqualExpression ~~ RelExpression
	EqualExpression !~ RelExpression

?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> Walter Bright wrote:
>> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dt2476$ii2$1@digitaldaemon.com...
>>> Walter Bright wrote:
>>>> Added match expressions.
>>>>
>>>> http://www.digitalmars.com/d/changelog.html
>>> So this
>>>
>>>     int[] x, y;
>>>     ...
>>>     x=y~~42;
>>>
>>> won't work anymore....
>>
>> That's right. Neither will:
>>
>>     x = !~y;
>>
>> It's in the same vein that:
>>
>>     x = y/*p;
>>
>> never worked, either. 
> 
> At least neither of those two is syntactically valid now.
> 
> Why are MatchExpression and NotMatchExpression separate nonterminals? Why not simply
> 
> MatchExpression:
>     EqualExpression ~~ RelExpression
>     EqualExpression !~ RelExpression

I think because MatchExpression injects a _Match* object into the following scope, while NotMatchExpression does not.


Sean

Sean Kelly wrote:
> Kris wrote:
>> "Sean Kelly" <sean@f4.ca> wrote ...
>>> Walter Bright wrote:
>>>> "Derek Parnell" <derek@psych.ward> wrote in message news:fdfenjm7wj46.1xmq12pyjxp8c$.dlg@40tude.net...
>>>>
>>>>> BTW, one side effect of the new matching syntax is that you don't have to
>>>>> explicitly import std.regexp.
>>>> That was on purpose. It uses a proxy.
>>> As cool as this is, I don't entirely like the prospect of cutting yet more ties between standard library components and runtime code.  My approach with Ares has been to separate the two, which until now has meant moving only std.utf into the DMD runtime.  Now it looks like std.regex will end up there as well (along with std.outbuffer perhaps). With the new language features, is there any reason to continue regex library support?  Just how much can't be done by the built-in syntax?
>>
>> I agree. And it's hard to fathom what the sudden rush to get this is about. I listed a number of (IMO) serious issues on the main forum, so I'll add my support here that hooking RegExp (and all its various imports) into the compiler is just bad news *at this point in time*
> 
> I'm willing to let the new language feature mature in place.  And while I think it's unnecessary given that it can be done just as well in library code, there's something about making regex handling a first class citizen that increases its appeal.  However, though I can understand Walter's desire to leverage existing code, I think it's a terrible mistake to make language features rely on library code, even if the relationship is concealed.  I don't think this is an issue for D in general (since the language spec obviously doesn't require this) so much as DMD specifically however.  For example, the GC code currently imports std.thread to do various things.  Now let's say that the private implementation of std.thread changes, and the changes have an impact on inlinable functions.  If the GC code isn't rebuilt, and if it was compiled with the -inline option set, all hell could break loose.
> 
> More generally however, such ties make it very difficult for third party library writers to provide alternate standard library implementations to work with DMD (similar to STLPort or STLSoft for C++), because the compiler runtime must be rebuilt to operate with any new library used. And it's difficult to be certain just what low-level features the runtime may rely on without well-defined points of interaction.  This is something I'm completely unfamiliar with coming from a C/C++ background, and it makes me wonder if any other compiled languages are like this as well.
> 
> Personally, I would love it if more attention were paid to defining necessary library interaction in D.  This is probably the most significant thing I've done in Ares and is what I think gives Ares the most credibility as a replacement standard library.  And while I would love for Walter to assume control of the DMD runtime and GC portions, doing so would require some care (and discussion) given to how language features such as regex are implemented: does the runtime truly need to interact with the standard library?  If so, how?
> 
> Implicit UTF conversions during foreach seems a reasonable language feature as such code is relatively simple to implement, but regular expression processing is somewhat complicated.  Is this a language feature that may be ignored by compilers that target embedded processors, simply because of size/complexity?  Can I expect to see shoddy regex implementations in some compilers such that I'm inclined to use a library implementation anyway?  My real concern isn't D now so much as D five years from now--I like the language enough that I really want it to succeed :-)
> 
>> Let's just suppose for a minute that the regex-templates work out well. It seems to me that any built-in support for regex (within the D grammar) would be nothing more than a thin veneer over the template syntax (for regex-templates), to make it somewhat  more palatable for the masses? That may not come to pass, but it seems that we should at least wait until there's a bit of education and experience in this regard, rather than hurriedly tie the grammar to something which clearly has a number of fundamental problems. Again; what's the big rush here?
> 
> It makes an odd sort of sense that a language designed by a compiler writer should have built-in regex support.  And it seems like Walter has been thinking about this for a while, so I'm willing to see how it goes.  But as a library writer, the way that Walter implements these changes gives me fits ;-)
> 
> 
> Sean

We (the Titan team) have run into this sort of issue with Titan. When trying to untangle the dmd runtime code, we have found huge reliance on library code, both libc and phobos. Another issue that makes porting difficult is the lack of a standard definition of what language features expand to what runtime functions. These two things have made dealing with the dmd runtime extremely hackish and untenable. Walter, for the love of Bob, do something about this.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:dt2j3t$13tb$1@digitaldaemon.com...
> Why are MatchExpression and NotMatchExpression separate nonterminals?

Because IfStatement handles them differently.

Kyle Furlong wrote:
> 
> We (the Titan team) have run into this sort of issue with Titan. When trying to untangle the dmd runtime code, we have found huge reliance on library code, both libc and phobos. Another issue that makes porting difficult is the lack of a standard definition of what language features expand to what runtime functions. These two things have made dealing with the dmd runtime extremely hackish and untenable. Walter, for the love of Bob, do something about this.

In the meantime, I suggest using Ares as a starting point.  It still uses libc functionality (which I think is unavoidable), but should otherwise be much cleaner to build off of.  If you have any questions about library interaction (since I've yet to document a lot of this) feel free to ask in the forums.


Sean

"Sean Kelly" <sean@f4.ca> wrote
> Kyle Furlong wrote:
>>
>> We (the Titan team) have run into this sort of issue with Titan. When trying to untangle the dmd runtime code, we have found huge reliance on library code, both libc and phobos. Another issue that makes porting difficult is the lack of a standard definition of what language features expand to what runtime functions. These two things have made dealing with the dmd runtime extremely hackish and untenable. Walter, for the love of Bob, do something about this.
>
> In the meantime, I suggest using Ares as a starting point.  It still uses libc functionality (which I think is unavoidable), but should otherwise be much cleaner to build off of.

I'll second that. Ares is as good an isolation of D compiler support as you're likely to see anywhere.

Derek Parnell wrote:
> On Wed, 15 Feb 2006 15:50:03 -0800, Walter Bright wrote:
> 
> 
>> Also, operating system wildcard thing isn't the one used, it's real regular expressions from std.regexp. So you'd write it as:
>>
>>     assert(".wav$" ~~ filename);
>>
>> which means any string ending in ".wav".
> 
> Should that be ...
> 
>        assert("\.wav$" ~~ filename);
> 
> otherwise it would also match things like "somefile.awav" because doesn't
> the "." in the regexp represents 'any-character'.
> 

Hrm. The compiler tells me it is an unidentified escape sequence.