On Mon, Feb 24, 2014 at 07:18:58PM -0800, Adam Wilson wrote: [...]
> Note that I as badly as I want std.lexer to be included I want it to pass a rigorous review. This review (and, is passing, subsequent inclusion) has opened up an opportunity to start using D at work that I did not expect and so I am kind of excited about it.
[...]

Me too, I'm looking forward to a well-designed lexer generator in Phobos. I will have lots of uses for it.

Sadly, I haven't had the time to review the proposed code as closely as I'd like.


T

-- 
What doesn't kill me makes me stranger.

On Tuesday, 25 February 2014 at 03:52:01 UTC, H. S. Teoh wrote:
> Sadly, I haven't had the time to review the proposed code as closely as
> I'd like.

Don't hesitate to ask for extending review period if you need so. Making good review is more important than meeting some arbitrary deadline.

On 2/24/14, 7:18 PM, Adam Wilson wrote:
> Note that I as badly as I want std.lexer to be included I want it to
> pass a rigorous review. This review (and, is passing, subsequent
> inclusion) has opened up an opportunity to start using D at work that I
> did not expect and so I am kind of excited about it.

I think it would be great if we rigged things such that std.lexer simplifies flint and makes it faster. From what I saw Brian has a very similar approach. I'm hoping for a few improvements, which I'll share soon.

Andrei

On 2014-02-21 13:12, Dicebot wrote:
> http://wiki.dlang.org/Review/std.lexer
>
> This is follow-up by Brian to his earlier proposal
> (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module
> focuses instead on generic lexer generation as discussed in matching
> voting thread.

I don't like it being a new top level module. I would name it std.language.lexer or std.lang.lexer.

-- 
/Jacob Carlborg

On Tuesday, 25 February 2014 at 20:48:08 UTC, Jacob Carlborg wrote:
> On 2014-02-21 13:12, Dicebot wrote:
>> http://wiki.dlang.org/Review/std.lexer
>>
>> This is follow-up by Brian to his earlier proposal
>> (http://wiki.dlang.org/Review/std.d.lexer). This time proposed module
>> focuses instead on generic lexer generation as discussed in matching
>> voting thread.
>
> I don't like it being a new top level module. I would name it std.language.lexer or std.lang.lexer.

std.lexer could be the umbrella for a bunch of different lexers. Then we could have std.lexer.xml, std.lexer.json, etc.

On Tuesday, 25 February 2014 at 20:48:08 UTC, Jacob Carlborg wrote:
> I don't like it being a new top level module. I would name it std.language.lexer or std.lang.lexer.

Don't know if it makes sense to introduce random package categorizatin. I'd love to see more hierarchy in Phobos too but we'd first need to agree to package separation principles then.

On Tuesday, 25 February 2014 at 20:21:17 UTC, Andrei Alexandrescu wrote:
> I think it would be great if we rigged things such that std.lexer simplifies flint and makes it faster. From what I saw Brian has a very similar approach. I'm hoping for a few improvements, which I'll share soon.
>
> Andrei

I'll be waiting for this list. In the meantime, I'm making a change to the string interning process to make it more threading friendly.

On Tuesday, 25 February 2014 at 23:17:56 UTC, Meta wrote:
> std.lexer could be the umbrella for a bunch of different lexers. Then we could have std.lexer.xml, std.lexer.json, etc.

I think that's a bit backwards. I'd rather have

std.d.lexer
std.d.ast
std.d.parser

than

std.lexer.d
std.parser.d
std.ast.d

On Monday, 24 February 2014 at 19:05:35 UTC, Dicebot wrote:
> Brian, do you have benchmarks for this proposal similar to ones you have provided in old review threads? (vs DMD frontend lexer)

Not yet, but I can create them before the review period ends.

On Wednesday, 26 February 2014 at 07:00:33 UTC, Brian Schott wrote:
> On Monday, 24 February 2014 at 19:05:35 UTC, Dicebot wrote:
>> Brian, do you have benchmarks for this proposal similar to ones you have provided in old review threads? (vs DMD frontend lexer)
>
> Not yet, but I can create them before the review period ends.

Thanks, that will be very interesting information to consider in context of DDMD.