D2 is really that stable as it is claimed to be?

[Peter Williams]

On 23/09/13 07:12, Jonathan M Davis wrote:
> On Sunday, September 22, 2013 16:50:05 Andrej Mitrovic wrote:
>> On 9/22/13, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
>>> Except that most of us don't care about the column number. It's of
>>> marginal
>>> benefit at best, and it harms compilation speed, so it's not worth it
>>> IMHO.
>>
>> You've never ran into lexer errors before have you?
>>
>> test.d(10): Error: found ',' when expecting ')'
>>
>> Now good luck finding where you forgot to put a closing brace in a
>> statement that uses traits or is(typeof( checks, such as this:
>>
>> static assert(0, format("%s does not implement '%s'",
>> __traits(identifier, typeof(this))), __FUNCTION__);
>>
>> It should have been:
>>
>> static assert(0, format("%s does not implement '%s'",
>> __traits(identifier, typeof(this)), __FUNCTION__));
>>
>> That's just a trivial case though.
>>
>> I run into these all the time, and I have to spend half a minute
>> scanning left and right trying to figure out where the damn missing
>> brace went. Marginal benefit my ass.
>
> Except that because the compiler doesn't know where the terminator should have
> been, it can't give you a column number anyway. In that case, it can't even
> give you the correct line number. At best, it can tell you the line number
> where the unmatched symbol was, and that's often not helpful (especially with
> braces). And even with parens, because the compiler doesn't know what you
> actually meant to do, it's not like it can tell you where exactly in the
> expression or statement you need to fix your code anyway. I really don't think
> that a column number would help much here.

With my dunnart LALR(1) parser generator, the lexer that's generated as 
part of the generated parser passes its tokens as class instances that 
give access to the line number and column at which the token was found 
in the text and the exact slice of the input text that was matched to 
form the token.  That information travels with the token (rather than 
being something you have ask the lexer for in most lexers e.g. flex) so 
it's always available no matter where the token pops up in the parser.

Similarly, when the parser does a reduce, the non terminal grammar 
symbol acquires the positional data for the first token in the reduced 
sequence.

Peter