Ellery Newcomer wrote:
Yeah, you're missing the point. The point is the D Language is billed as
one whose lexer is completely independent of its parser, which is
completely independent of its semantic analysis. The parser must be able
to decide all of these without any help from semantic. Anything less is
either failure or just plain wrong.
So you are following those steps from
http://digitalmars.com/d/2.0/lex.html. I don't think these are strict
restrictions to allow your tool to be called a D language parser
preventing you from re parsing. I think it is really trying to point out
the first few steps and perhaps should be re written as:
1 source character set
The source file is checked to see what character set it is, and the
appropriate scanner is loaded. ASCII and UTF formats are accepted.
2 script line
If the first line starts with #! then the first line is ignored.
3 parse
Also from this page http://digitalmars.com/d/2.0/overview.html
features to drop: C source code compatibility.
This is not valid code with dmd v2.030 because D is not strictly
compatible with C/C+.
struct A
{
int i;
}
void main()
{
A(a);
}
Now that I've tested that with structs, classes, and typedef'd int none
of which worked. This does compile however:
void main()
{
int(a);
a = 2;
}
From that dmd compatibility should be far simpler but going beyond that
would be nicer.
it is infinitely better than mixing
semantic and syntactic analysis
I didn't recommend that.
But question remains: how does the compiler decide this?
Built in types have the extra C compatibility. Dmd doesn't like this
though and if it matters to you enough, report it as a bug:
alias int T;
void main()
{
T(a);
a = 2;
}
You are right, though, none of this is complex, just tedious. Reading
the compiler's source code especially, though it sounds like I'm not
going to get answers any other way.
If you have a parser that allows that syntax to work a bit more than
could you please provide an example of code here that is completely
ambiguous to the compiler.
