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
