Parsing D Maybe Not Such a Good Idea <_<;

[cy via Digitalmars-d]

On Wednesday, 15 June 2016 at 07:16:31 UTC, Basile B. wrote:

> You're right it's not so simple and you're also right about 
> "everything", my "everything" is not used adequatly...

Sorry, I don't mean to complain. Actually the work has already 
all been done, rather elegantly in fact. If libdparse can get 
through a significant subset of D2 code, I have to say I'm pretty 
impressed with the project, and can't praise it enough.

https://github.com/Hackerpilot/libdparse // disclaimer: this link 
not endorsed by the hackerpilot org ltd

It already has a D formatter in it, which dumps (prettified!) D 
code to any sort of output range, and there's a case in it for 
every single kind of node in the AST.

(speaking of which, when are we getting static switch statements?)

What I meant by "D is not simple" isn't that I'm up a creek, 
without a paddle, but that the paddle is really complex, and I'd 
have no hope of tackling it if it wasn't already done. The 
complexity of D's syntax is not so much a problem here, as a 
spectacle.

> It depends on the grammatical construct you want to parse. But 
> it's already much more simple when the comments are removed 
> from the lexical token list.

I suppose. What's complicated is the shoving of expressions 
everywhere, since those spider out to all possible forms of 
construct. That means the difficulty of parsing does NOT depend 
on the grammatical construct you want to parse, except for a few, 
very minor constructs, only the ones that don't even 
*potentially* include expressions in their grammar.

So, regardless of what you're doing, you pretty much have to 
handle every single kind of construct, but if "handle" means 
"transform, then output" and you can separate those two steps, 
then if someone does all the output for you, the "transform" step 
can be very simple and specific. Not because you can remove the 
comment nodes, but because you can ignore ALL nodes that you're 
not interested in transforming.