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 <[email protected]> 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


Reply via email to