Future of Descent and D Eclipse IDE

[Bruno Medeiros]

On 26/05/2010 16:45, Ellery Newcomer wrote:
> On 05/25/2010 03:31 PM, Bruno Medeiros wrote:
>> On 25/05/2010 03:15, Ary Borenszweig wrote:
>>> On 05/24/2010 08:38 AM, Bruno Medeiros wrote:
>>>
>>> * Porting DMD source to Java was done manually and it's a very boring
>>> and long task, and we need to find a way to automate it if we'd like to
>>> support really good integration with the language (I mean, real semantic
>>> value, and because D is not dynamic I think this is worth it).
>>> * The DMD source was modified a little bit for performance reasons and
>>> for integration with Descent so now it contains bugs that are very hard
>>> to fix.
>>
>> That's actually exactly the concerns I had from the start with doing
>> that approach. Even if we had an easy way to automate the port, I think
>> we would still have a code that has issues of performance and
>> scalability. And yet if we would try to modify it to address those
>> issues, we would most likely introduce hard to correct bugs, and/or make
>> the automated porting process (if we had one) much more complicated, if
>> not impossible (aka, reverting to doing a lot of manual work).
>>
>> That's why I think the approach of porting the full DMD frontend is not
>> good, even it was more automated. So for me its either:
>>
>> * Port and use the DMD parser only, and implement semantic analysys
>> features by scratch. This is Mmrnmhrm's current approach, and would mean
>> the semantic capabilities would be much less than Descent: likely just
>> resolving references (for code completion), but no semantic errors or
>> CTFE debug.
>>
>> * Try and build the parser and semantic engine with the help of some
>> other tool, like IMP for example.
>
> If anyone cares, I have a functioning ANTLR grammar for d1 for which I
> someday intend to write semantic for. I'm also mostly done with an ANTLR
> grammar for d2.
>

Yes, that might be quite interesting. With that, if going with the 
Mmrnmhrm approach, we could replace the DMD parser with the ANTLR one, 
which could be faster overall. Although the DMD parsing itself is likely 
quite fast, the thing is Mmrnmhrm converts the DMD AST to its own AST 
structure, which has quite a different class hierarchy. With the ANTRL 
parser this new AST could be created straight away, which might be 
faster overall. But this would have to be tested. In any case, its not 
something for the near future, but its good to know.

> They're a bit on the slow side, but I think they can successfully parse
> things that dmd currently can't.

What do mean slow side? And what things can it parse that DMD can't? (I 
wasn't aware there were things DMD could not parse)

-- 
Bruno Medeiros - Software Engineer