dmd support for IDEs and the D tool chain

[Ellery Newcomer]

Nick Sabalausky wrote:
> "Ellery Newcomer" <ellery-newcomer at utulsa.edu> wrote in message 
> news:hbak0n$q5b$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Denis Koroskin" <2korden at gmail.com> wrote in message
>>> news:op.u1v7jdgco7cclz at korden-pc...
>>>> Yes, it's a DMD port. Unfortunately, there is no other mature D 
>>>> front-end
>>>> at present. Other folks are working on D compilers (dil, dang, ...) but
>>>> the progress is very slow.
>>> FWIW, I've been meaning to try to write a D grammar for GOLD when I get a
>>> chance (the Haxe grammar I wrote only took a few days). If that pans out
>>> (depends just how simple and unambiguous the grammar is), then that could 
>>> be
>>> used with Goldie as a starting point (ie, lex/parse would be taken care 
>>> of.
>>> Semantic analysis, optimization and back-end would need to be added in).
>>>
>> All but the hard parts :)
> 
> Yea, like I said, "FWIW" ;)
> 
>> I could count the number of places that are ambiguous syntactically or
>> semantically on one hand, and maybe the number of places that require
>> arbitrary lookahead also. Do LALR parsers care about arbitrary
>> lookahead? LL(k) parsers do.
> 
> Beats me, I'm not nearly as up on parsing theory as I'd like to be. Could 
> you give me a simple example? 
> 
> 
Well, let's see here...

PrimExp -> structLiteral
PrimExp -> functionLiteral

and suppose

structLiteral => { /* really, really looooooooooong expression*/ }

functionLiteral => { statement }
functionLiteral => { /* really, really looooooooooong expression*/ ; }

In an LL(k) parser, when you get to PrimExp, you have to know which
choice to make based on the first k lookahead characters (probably
translates to '{' and one token past that). Obviously, that won't work
for this piece, so it isn't LL(k). You have to try parsing the one, and
back up and parse the other if the first one fails (dmd should do this,
but currently it just looks ahead for the first semicolon. come to think
of it, I should try patching that..)

ANTLR has pretty good support for backtracking, so writing a D grammar
for it wasn't too difficult, but then the resultant performance isn't
anything near what I'd like.

But what I'm wondering about LALR is will it have to back up if it
chooses wrong, or can it sail on through in one parse attempt. I bet it
can.

And how about actual ambiguity? How well does GOLD handle that?