clayasaurus wrote:
> 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.

Try "\.wav$"r :-)


Sean

"Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dt2mkm$17aa$1@digitaldaemon.com...
> 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.

Sure, but I'm not sure why this is a problem.

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

"Sean Kelly" <sean@f4.ca> wrote in message news:dt2uj7$1e4l$1@digitaldaemon.com...
> Try "\.wav$"r :-)

r"\.wav$"

James Dunne wrote:
> pragma wrote:
> 
>> In article <dt0k9b$27jr$1@digitaldaemon.com>, Kyle Furlong says...
>>
>>> Walter Bright wrote:
>>>
>>>> Added match expressions.
>>>>
>>>> http://www.digitalmars.com/d/changelog.html
>>>>
>>>>
>>>>
>>>
>>> Is it possible to drop in compile-time regex support? (i.e. Eric's solution)
>>
>>
>>
>> IMHO, it's not quite ready for prime-time yet.  In fact, some parts of it are
>> still somewhat incomplete. :(
>>
>> - Eric Anderton at yahoo
> 
> 
> Not to knock Eric's great efforts at compile-time regex (which is seriously cool, btw), but I would be more impressed at code generation of regex parsing.  Have the compiler itself write out some highly optimized goto-like code and have it parse known regex strings at runtime in the fastest way possible.  Reminds me of the approach of the Ragel state machine (link on D Links page), but doesn't have to be anywhere near as complicated.
> 

I am not commenting on the regex support in particular (I haven't used it yet), however I think that the introduction if this _type_ of feature is a good thing, if it is done carefully.

To elaborate, the use of templates to implement compile time regex just seems like an error prone mess (a fantastic, made by a genus mess, but still a mess). While templates can be vary powerful and get a lot of stuff done, I think that the language should include support for compile time programming that is not just a side effect of other features. As an example of what I would like to see more of, I posted a while ago proposing a witheach statement.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/32232

There are a few other tasks that I think should be easily done at compile time construction of a balanced binary search tree for instance.

Walter Bright wrote:
> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dt2mkm$17aa$1@digitaldaemon.com...
>> 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.
> 
> Sure, but I'm not sure why this is a problem.
> 
>> 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.
> 
> 
> 
> 

It basically forces us to write our own libc. And yes one can argue that libc is as necessary as air for any platform, but I'm of the purist type, and feel that the runtime should be self contained.

You also did not respond to my request for a runtime standard, is this something you are unwilling to do? i.e. is each vendor's runtime going to be completely incompatible with others?

"Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dt3gn8$1sq0$1@digitaldaemon.com...
> Walter Bright wrote:
>> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:dt2mkm$17aa$1@digitaldaemon.com...
>>> 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.
>>
>> Sure, but I'm not sure why this is a problem.
>>
>>> 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.
>
> It basically forces us to write our own libc. And yes one can argue that libc is as necessary as air for any platform, but I'm of the purist type, and feel that the runtime should be self contained.

Since D is designed to interface directly to C, the C runtime is kind of a given. I also don't see much point in reimplementing things like strlen, strtod, etc. These have been around for decades, they're well optimized, and bug free.

> You also did not respond to my request for a runtime standard, is this something you are unwilling to do? i.e. is each vendor's runtime going to be completely incompatible with others?

I'm not sure what you're asking. Are you asking if Phobos is a D standard?

Walter Bright wrote:
> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message
> news:dt3gn8$1sq0$1@digitaldaemon.com...
>> Walter Bright wrote:
>>> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message
>>> news:dt2mkm$17aa$1@digitaldaemon.com...
>>>> 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.
>>> Sure, but I'm not sure why this is a problem.
>>>
>>>> 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.
>> It basically forces us to write our own libc. And yes one can argue that
>> libc is as necessary as air for any platform, but I'm of the purist type,
>> and feel that the runtime should be self contained.
> 
> Since D is designed to interface directly to C, the C runtime is kind of a
> given. I also don't see much point in reimplementing things like strlen,
> strtod, etc. These have been around for decades, they're well optimized, and bug free.
> 
>> You also did not respond to my request for a runtime standard, is this
>> something you are unwilling to do? i.e. is each vendor's runtime going to
>> be completely incompatible with others?
> 
> I'm not sure what you're asking. Are you asking if Phobos is a D standard?
> 
> 
> 
> 

So your dmd compiler emit's references to the _d_whatever extern(C) functions in the runtime, correct? I'm asking if this is going to be a standard, part of the spec, or vendor specific.

Walter Bright wrote:
> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message
> news:dt3gn8$1sq0$1@digitaldaemon.com...
> 
>> You also did not respond to my request for a runtime standard, is this
>> something you are unwilling to do? i.e. is each vendor's runtime going to
>> be completely incompatible with others?
> 
> I'm not sure what you're asking. Are you asking if Phobos is a D standard?

I think Kyle is wondering whether a compiler writer could simply sit down and write a D compiler, sans standard library, given the D spec.  I think this is possible insofar as language features are concerned, but it may be less clear regarding any points of contact between the runtime and the GC or standard library code.  For example, internal/gc/gc.d contains a bunch of extern (C) functions (prefixed with "_d_") which probably really belong to the runtime code.  But if this is true, what are the points of contact between the runtime and GC?  Using Phobos as a guide, one might think a compiler writer must provide a garbage collector as a part of the runtime, while I consider these logically separate libraries.  I think the real goal here is to define a clear separation of labor, so a compiler writer can do his part, a library writer his part, an platform writer his part, and each can be assured that if they follow the spec then their libraries should link against any implementation of the other pieces and work without error.  This is really what I'm making an effort to define, and why I fussed so much over this RegExp business.  Until this last release, things had been distilled to a few well-defined extern (C) functions--no need for imports at all :-)


Sean

Sean Kelly wrote:
> Walter Bright wrote:
>> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message
>> news:dt3gn8$1sq0$1@digitaldaemon.com...
>>
>>> You also did not respond to my request for a runtime standard, is this
>>> something you are unwilling to do? i.e. is each vendor's runtime going to
>>> be completely incompatible with others?
>>
>> I'm not sure what you're asking. Are you asking if Phobos is a D standard?
> 
> I think Kyle is wondering whether a compiler writer could simply sit down and write a D compiler, sans standard library, given the D spec.  I think this is possible insofar as language features are concerned, but it may be less clear regarding any points of contact between the runtime and the GC or standard library code.  For example, internal/gc/gc.d contains a bunch of extern (C) functions (prefixed with "_d_") which probably really belong to the runtime code.  But if this is true, what are the points of contact between the runtime and GC?  Using Phobos as a guide, one might think a compiler writer must provide a garbage collector as a part of the runtime, while I consider these logically separate libraries.  I think the real goal here is to define a clear separation of labor, so a compiler writer can do his part, a library writer his part, an platform writer his part, and each can be assured that if they follow the spec then their libraries should link against any implementation of the other pieces and work without error.  This is really what I'm making an effort to define, and why I fussed so much over this RegExp business.  Until this last release, things had been distilled to a few well-defined extern (C) functions--no need for imports at all :-)
> 
> 
> Sean

Well put Sean, I would be very interested in Walter's take on these issues.

BCS wrote:
> To elaborate, the use of templates to implement compile time regex just seems like an error prone mess (a fantastic, made by a genus mess, but still a mess). 

Probably nobody thinks that compile time regexes should be implemented with template metaprogramming.

While D template programming screams compared to C++, shoving work on the template system does slow down compilation unnecessarily, compared to doing things 'the proper way'. This would erode the absolutely coolest feature DMD has: a blazing compilation speed.

> While templates can be vary powerful and get a lot of stuff done, I think that the language should include support for compile time programming that is not just a side effect of other features.

At the time, I think they just served to demonstrate a few things:

 - that you (or actually, Don) really can do most amazing things with templates

 - that showing this would motivate Walter to add effort and priority to implementing them properly (i.e. non-template)

 - serve as a vehicle to demonstrate the utility (of both template programming in itself, and the utility of compile-time regexes)