Mono-D v0.4.9 - Rough formatting capability

[Bruno Medeiros]

On 24/01/2013 15:11, Paulo Pinto wrote:
> On Thursday, 24 January 2013 at 13:12:31 UTC, Bruno Medeiros
> wrote:
>> On 21/01/2013 21:14, alex wrote:
>>> Hi everyone,
>>>
>>> No, the entire formatting engine is NOT finished yet. :P
>>> Anyway I've created a good compromise solution between releasing
>>> stuff early and having a fairly nice formatting result:
>>>
>>> I just let the indenting engine calculate the indents of all
>>> lines of the code - and fix all the incorrect indents afterwards.
>>> It works quite fast & reliable(?) - I hope it won't throw very
>>> often + you don't have to worry about resetting your code to an
>>> earlier state via [Ctrl+Shift][Z]
>>>
>>> Indenting only parts of the code is possible either! - So you
>>> don't have to worry about your entire code getting messed up
>>> probably ;)
>>>
>>>
>>> More info @ http://mono-d.alexanderbothe.com
>>>
>>> Issues: https://github.com/aBothe/Mono-D/issues
>>
>> That's a lot of continuing nice work coming out from there, impressive!
>>
>> BTW, something I've been meaning to ask. I see that in Mono-D you've
>> developed a hand-written D parser. How long did it take you to write
>> that? Did you test it extensively or not so much?
>>
>> I'm embarking on that same task in Java, for DDT, and wondering how
>> long it will take to build a quality parser. So far, it doesn't seem
>> writing the actual parser will take that long, but writing extensive
>> tests for it is seeming exceedingly complicated (or just lengthy and
>> time-consuming). I'm usually a big proponent of TDD, but when writing
>> a lot of tests starts to take a lot of time compared to the code being
>> tested (in this case, maybe 1.5 times the effort/time of the code
>> being tested), I'm not so certain it's the right call to spend so much
>> time writing tests...
>
> Are you making use of JavaCC or ANTLR?

No, I thought I was going to initially, but the more I explored it the 
less I was up for it. This is what I wrote in the DDT forum some time ago:
"
At the moment I'm still just on an exploratory phase: learning more 
about ANTLR, how it generates code, I looked a bit at Gyula's ANTLR 
grammar code, but I am also looking into the possibility of writing a 
handwritten parser. In particular, some interesting reads:
http://stackoverflow.com/questions/6319086/are-gcc-and-clang-parsers-really-handwritten
http://programmers.stackexchange.com/questions/17824/should-i-use-a-parser-generator-or-should-i-roll-my-own-custom-lexer-and-parser
It's a bit hard to get a good opinion on this though, because the 
shortcomings they mention for parser generators (bad error messages, 
difficulty to do error recovery), apply mainly to certain types of PGs, 
like LR ones, but not the LL or PEG ones (like ANTLR), which are good at 
error reporting&recovery. But still, can handwritten parsers be 
significantly better at error reporting&recovery than LL/PEG parser 
generators? Hum...
"
But the more I was trying ANTLR and reading about it, the more I got the 
impression it was a huge abstraction that added a lot of complexity (in 
learning and understanding), but didn't actually save you that much effort.
I mean, sure, if you just want to recognize a language, it saves a lot 
of effort vs. writting a custom parser. But to actually generate an AST, 
proper source range, DDoc comment annotations, parse trickier rules, 
handle error recovery properly, and make sure the parser is efficient, 
it seemed like a daunting task. I felt I would have to become an ANLTR 
expert (read the book, and the theory behind it) for something that 
seemed trivial and fairly easy to do without a parser generator.
This is by no means a fully-fledged, 100% assured opinion, but it's what 
I got so far. Comments and ideas are welcome. But from what I read from 
stackexchange a lot of other people seem to share this opinion (that 
it's better to write hand-written), although I don't know which kind of 
context and requirements they are comming from.


-- 
Bruno Medeiros - Software Engineer