Mono-D v0.4.9 - Rough formatting capability

Paulo Pinto pjmlp at progtools.org
Fri Jan 25 09:18:01 PST 2013


On Friday, 25 January 2013 at 12:31:12 UTC, Bruno Medeiros wrote:
> 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.

Thanks for the lengthy reply.

I was just curious.

Hand written parsers tend to better on error messages, that is
true.

Personally I tend to use parser generators, but since university
days I just do DSL kind of languages anyway.

The main problem is when you start parsing things that require a
lot of backtracking or do not fit well in a LL(k) grammar
description.

--
Paulo


More information about the Digitalmars-d-announce mailing list