On 9/12/2013 1:15 AM, Brian Schott wrote:
> I got some time to work on the lexer this evening. Changeset here:
> https://github.com/Hackerpilot/phobos/commit/9bdb7f97bb8021f3b0d0291896b8fe21a6fead23#std/d/lexer.d
>
>
> The DDoc page has moved here:
> http://hackerpilot.github.io/experimental/std_lexer/phobos/std_d_lexer.html

Great!


> * There are a few more unit tests now

I strongly recommend running the unit tests with -cov. A lexer should be able to get near 100% coverage with the unit tests.

> * bitAnd renamed to amp
> * slice rename to dotdot
> * Much more cross-referencing in the doc comments
> * Start line and column can be specified in the lexer config

On Thursday, 12 September 2013 at 23:40:55 UTC, Walter Bright wrote:
> I strongly recommend running the unit tests with -cov. A lexer should be able to get near 100% coverage with the unit tests.

Some of the code is only present to be used at compile-time to generate switch statements inside of the lexer. -cov doesn't show code that's executed at compile-time to be covered, and it couldn't show meaningful line numbers on code that's generated and mixed in.

That being said, it's currently 70% covered. I'll be making another pass over the code later to fill in some of the gaps.

On 9/12/2013 4:57 PM, Brian Schott wrote:
> On Thursday, 12 September 2013 at 23:40:55 UTC, Walter Bright wrote:
>> I strongly recommend running the unit tests with -cov. A lexer should be able
>> to get near 100% coverage with the unit tests.
>
> Some of the code is only present to be used at compile-time to generate switch
> statements inside of the lexer. -cov doesn't show code that's executed at
> compile-time to be covered, and it couldn't show meaningful line numbers on code
> that's generated and mixed in.

That's right.


> That being said, it's currently 70% covered. I'll be making another pass over
> the code later to fill in some of the gaps.

Thanks.

We are talking about parameters here, not arguments. But overall, that isn't the point.

If I have int a = 3 as an argument in the first set of (), I still have no clue if it is a runtime or compile time parameter. But ref int a = 3 ?

Doing so, you ends up with a lot of ambiguous node (like FunctionArgumentOrValueTemplateParameter) and have to manage that complexity, or have to backtrack on the parsing and fix ambiguous node when you have enough information.

Discussion has slowed down and thread is fading away.

I personally have not noticed any crucial objections (ones that can't be figured out during normal pull request review process). Brian, what is your state on this? Is there something you want to add/change before the voting gets initiated?

On Tuesday, 17 September 2013 at 15:31:00 UTC, Dicebot wrote:
> Discussion has slowed down and thread is fading away.
>
> I personally have not noticed any crucial objections (ones that can't be figured out during normal pull request review process). Brian, what is your state on this? Is there something you want to add/change before the voting gets initiated?

I had some comments that nobody addressed. Mostly about firing several instances of the lexer with the same identifier pool.

On Tuesday, 17 September 2013 at 16:34:01 UTC, deadalnix wrote:
> On Tuesday, 17 September 2013 at 15:31:00 UTC, Dicebot wrote:
>> Discussion has slowed down and thread is fading away.
>>
>> I personally have not noticed any crucial objections (ones that can't be figured out during normal pull request review process). Brian, what is your state on this? Is there something you want to add/change before the voting gets initiated?
>
> I had some comments that nobody addressed. Mostly about firing several instances of the lexer with the same identifier pool.

Well, I suppose only Brian can address it :) I am only checking if there are no commonly repeated objections that are likely to ruin the voting. There are plenty of comments of course and I would recommend Brian to at least make some statement about those before voting but that is his call.

There is a possibility to mention one issue as a blocker when voting though, that will be taken into consideration when counting actual votes.

On Tuesday, 17 September 2013 at 16:48:44 UTC, Dicebot wrote:
> On Tuesday, 17 September 2013 at 16:34:01 UTC, deadalnix wrote:
>> On Tuesday, 17 September 2013 at 15:31:00 UTC, Dicebot wrote:
>>> Discussion has slowed down and thread is fading away.
>>>
>>> I personally have not noticed any crucial objections (ones that can't be figured out during normal pull request review process). Brian, what is your state on this? Is there something you want to add/change before the voting gets initiated?
>>
>> I had some comments that nobody addressed. Mostly about firing several instances of the lexer with the same identifier pool.
>
> Well, I suppose only Brian can address it :) I am only checking if there are no commonly repeated objections that are likely to ruin the voting. There are plenty of comments of course and I would recommend Brian to at least make some statement about those before voting but that is his call.
>
> There is a possibility to mention one issue as a blocker when voting though, that will be taken into consideration when counting actual votes.

I've been busy with things that aren't D-related recently, but I should have time the rest of this week to address the lexer.

On Wednesday, 11 September 2013 at 15:02:00 UTC, Dicebot wrote:
> std.d.lexer is standard module for lexing D code, written by Brian Schott

Brian, have you got any plans to write common lexer/parser generator based on context-free grammar (CFG) or parsing expression grammar (PEG), not only for D grammar?

Something like this:
https://github.com/PhilippeSigaud/Pegged

On Tuesday, 17 September 2013 at 20:14:36 UTC, Brian Schott wrote:
> I've been busy with things that aren't D-related recently, but I should have time the rest of this week to address the lexer.

Ok, please notify me then once you feel ready for voting / extra review ( public at dicebot.lv )

Thanks for you work.