www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Mono-D v0.4.9 - Rough formatting capability

reply "alex" <info alexanderbothe.com> writes:
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
Jan 21 2013
next sibling parent reply "F i L" <witte2008 gmail.com> writes:
Thanks Alex, even though I don't use auto-formatting (I never did 
like that).
Jan 21 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
 Thanks Alex, even though I don't use auto-formatting (I never 
 did like that).
I use it rarely either - but some others asked whether I could do this - and now there it is :)
Jan 21 2013
parent reply "mist" <none none.none> writes:
On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote:
 On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
 Thanks Alex, even though I don't use auto-formatting (I never 
 did like that).
I use it rarely either - but some others asked whether I could do this - and now there it is :)
Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!
Jan 22 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote:
 On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote:
 On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
 Thanks Alex, even though I don't use auto-formatting (I never 
 did like that).
I use it rarely either - but some others asked whether I could do this - and now there it is :)
Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!
Uhm..what is an auto-formatter in your eyes? Automatic formatting when you typed a '}' for instance? Or just the explicit possibility to let a program format your code? I mean, once the code got indented correctly, why should it ever be passed through a formatter again? Just to see that it's actually been indented correctly? Hmm..
Jan 22 2013
parent reply "mist" <none none.none> writes:
I always define project code style policies in Eclipse code style 
settings and run auto-format (Ctrl+Shift+F) on new code always 
before commiting to ensure my nasty personal preferences have not 
slipped out of subconscious. It also converts all whitespaces 
consistently to match project settings and sometimes I forget to 
setup tab->space autoreplacement for external editors.

In-place formatting is not that important for me.

On Tuesday, 22 January 2013 at 14:44:15 UTC, alex wrote:
 On Tuesday, 22 January 2013 at 10:26:21 UTC, mist wrote:
 On Monday, 21 January 2013 at 21:35:11 UTC, alex wrote:
 On Monday, 21 January 2013 at 21:32:38 UTC, F i L wrote:
 Thanks Alex, even though I don't use auto-formatting (I 
 never did like that).
I use it rarely either - but some others asked whether I could do this - and now there it is :)
Lack of auto-formatter was the reason I stopped using Mono-D some time ago :) Awesome update, good luck with this!
Uhm..what is an auto-formatter in your eyes? Automatic formatting when you typed a '}' for instance? Or just the explicit possibility to let a program format your code? I mean, once the code got indented correctly, why should it ever be passed through a formatter again? Just to see that it's actually been indented correctly? Hmm..
Jan 22 2013
parent "alex" <info alexanderbothe.com> writes:
On Tuesday, 22 January 2013 at 15:54:46 UTC, mist wrote:
 I always define project code style policies in Eclipse code 
 style settings and run auto-format (Ctrl+Shift+F) on new code 
 always before commiting to ensure my nasty personal preferences 
 have not slipped out of subconscious. It also converts all 
 whitespaces consistently to match project settings and 
 sometimes I forget to setup tab->space autoreplacement for 
 external editors.

 In-place formatting is not that important for me.
So that's the exact thing I'm trying to implement: To define an IDE- or project-wide formatting policy and let this control the code style. Let's see how far I can do it :)
Jan 22 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
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... -- Bruno Medeiros - Software Engineer
Jan 24 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-24 14:12, Bruno Medeiros wrote:

 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...
How about reusing the one in VisualD, it's written in D? Sure it's a bit more work since it's not written in a Java compatible language but it might be worth it. -- /Jacob Carlborg
Jan 24 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 24/01/2013 13:25, Jacob Carlborg wrote:
 On 2013-01-24 14:12, Bruno Medeiros wrote:

 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...
How about reusing the one in VisualD, it's written in D? Sure it's a bit more work since it's not written in a Java compatible language but it might be worth it.
If I was going with that approach I likely would rather port the MonoD parser since it looks just as good, if not better, and C# would be easier to port to Java than D. But the descent.compiler experience (parser ported from DMD's parser) put me off that approach of porting from a parser in another language (although the VisualD parser might have less shortcomings than using the DMD parser since at least VisualD's parser is designed for IDE use). I want to have more control over the parser, and be able to effect my own changes in it (something tricky if you're porting - unless you give up the porting at some point, and just fork your own version and use ir from there) -- Bruno Medeiros - Software Engineer
Jan 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 13:01, Bruno Medeiros wrote:

 If I was going with that approach I likely would rather port the MonoD
 parser since it looks just as good, if not better, and C# would be
 easier to port to Java than D.
 But the descent.compiler experience (parser ported from DMD's parser)
 put me off that approach of porting from a parser in another language
 (although the VisualD parser might have less shortcomings than using the
 DMD parser since at least VisualD's parser is designed for IDE use). I
 want to have more control over the parser, and be able to effect my own
 changes in it (something tricky if you're porting - unless you give up
 the porting at some point, and just fork your own version and use ir
 from there)
I didn't say anything about porting :) I was suggesting you integrate the VisualD parser without porting it. That's why I suggested the one in VisualD and not the one in Mono-D. -- /Jacob Carlborg
Jan 25 2013
next sibling parent reply "alex" <info alexanderbothe.com> writes:
On Friday, 25 January 2013 at 13:43:46 UTC, Jacob Carlborg wrote:
 I didn't say anything about porting :) I was suggesting you 
 integrate the VisualD parser without porting it. That's why I 
 suggested the one in VisualD and not the one in Mono-D.
I already suggested Rainer to make a native/non-native interface between VisualD and D_Parser - this will probably happen via COM or so.. and I dunno anything about that technique. I just can make sure that the parser library is fully stand-alone, only depending on .net internals. Let's see :)
Jan 25 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-25 20:00, alex wrote:

 I already suggested Rainer to make a native/non-native interface between
 VisualD and D_Parser - this will probably happen via COM or so.. and I
 dunno anything about that technique. I just can make sure that the
 parser library is fully stand-alone, only depending on .net internals.
 Let's see :)
It should provide an C interface, then it can be connected to anything. -- /Jacob Carlborg
Jan 25 2013
next sibling parent reply "alex" <info alexanderbothe.com> writes:
On Friday, 25 January 2013 at 20:34:28 UTC, Jacob Carlborg wrote:
 On 2013-01-25 20:00, alex wrote:

 I already suggested Rainer to make a native/non-native 
 interface between
 VisualD and D_Parser - this will probably happen via COM or 
 so.. and I
 dunno anything about that technique. I just can make sure that 
 the
 parser library is fully stand-alone, only depending on .net 
 internals.
 Let's see :)
It should provide an C interface, then it can be connected to anything.
Why not wrap dmd's front-end?
Jan 25 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-26 01:23, alex wrote:

 Why not wrap dmd's front-end?
The problem with the DMD frontend is that it's not made to be used in on its own, like in an IDE. -- /Jacob Carlborg
Jan 26 2013
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 25.01.2013 21:34, Jacob Carlborg wrote:
 On 2013-01-25 20:00, alex wrote:

 I already suggested Rainer to make a native/non-native interface between
 VisualD and D_Parser - this will probably happen via COM or so.. and I
 dunno anything about that technique. I just can make sure that the
 parser library is fully stand-alone, only depending on .net internals.
 Let's see :)
It should provide an C interface, then it can be connected to anything.
COM is the natural choice when interfacing native code on Windows with C#. On other platforms it might be different. The semantic engine in Visual D is separated into another process and communicates with the IDE plugin through a number of "commands", just using this interface: https://github.com/rainers/visuald/blob/master/vdc/ivdserver.d . This can easily be mapped to C calls. There's also an implementation of that interface using D_Parser (https://github.com/rainers/visuald/tree/master/vdc/abothe), but it isn't complete yet.
Jan 26 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Saturday, 26 January 2013 at 08:22:39 UTC, Rainer Schuetze 
wrote:
 On 25.01.2013 21:34, Jacob Carlborg wrote:
 On 2013-01-25 20:00, alex wrote:

 I already suggested Rainer to make a native/non-native 
 interface between
 VisualD and D_Parser - this will probably happen via COM or 
 so.. and I
 dunno anything about that technique. I just can make sure 
 that the
 parser library is fully stand-alone, only depending on .net 
 internals.
 Let's see :)
It should provide an C interface, then it can be connected to anything.
COM is the natural choice when interfacing native code on Windows with C#. On other platforms it might be different. The semantic engine in Visual D is separated into another process and communicates with the IDE plugin through a number of "commands", just using this interface: https://github.com/rainers/visuald/blob/master/vdc/ivdserver.d . This can easily be mapped to C calls. There's also an implementation of that interface using D_Parser (https://github.com/rainers/visuald/tree/master/vdc/abothe), but it isn't complete yet.
Concerning completion server...why not a completion server? :D - I mean, it'll be launched as soon as VisualD launches..and then you can pipe-through commands etc. to interact like it's done the mspdbsrv already. That's imho even easier than using COM + can be driven even as a web server..which would be a real dream then!
Jan 26 2013
parent reply "alex" <info alexanderbothe.com> writes:
On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote:
 Concerning completion server...why not a completion server? :D 
 - I mean, it'll be launched as soon as VisualD launches..and 
 then you can pipe-through commands etc. to interact like it's 
 done the mspdbsrv already. That's imho even easier than using 
 COM + can be driven even as a web server..which would be a real 
 dream then!
Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea?
Jan 26 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 26.01.2013 13:09, alex wrote:
 On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote:
 Concerning completion server...why not a completion server? :D - I
 mean, it'll be launched as soon as VisualD launches..and then you can
 pipe-through commands etc. to interact like it's done the mspdbsrv
 already. That's imho even easier than using COM + can be driven even
 as a web server..which would be a real dream then!
Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea?
That's actually what the Visual D semantic server process does. Syntax highlighting and indenting are done in the plugin, though. These don't need anything more than lexing so far and must be fast. Specifying import paths and compile options isn't so easy, because you can have different options for different projects in the solution, meaning the same file might be even used with different settings. That's also one of the points where integration of D_Parser is kind of brittle.
Jan 26 2013
parent "alex" <info alexanderbothe.com> writes:
On Saturday, 26 January 2013 at 12:28:11 UTC, Rainer Schuetze 
wrote:
 On 26.01.2013 13:09, alex wrote:
 On Saturday, 26 January 2013 at 11:46:27 UTC, alex wrote:
 Concerning completion server...why not a completion server? 
 :D - I
 mean, it'll be launched as soon as VisualD launches..and then 
 you can
 pipe-through commands etc. to interact like it's done the 
 mspdbsrv
 already. That's imho even easier than using COM + can be 
 driven even
 as a web server..which would be a real dream then!
Some additional thoughts: All you need to specify at startup are include paths and some completion options or so. Then while editing, you either pass changes incrementally or push the entire document content to the server. The server parses that document then and updates the internal parse cache. These parse caches will be used for completion then. As you request e.g. the completion window to open or some tooltip info, you just pass the module name, the caret location and a command to the server - it'll answer then with all the items that shall be shown in the completion list or in the tooltip box. Furthermore, stuff like indenting and formatting could be interfaced, too - just push the document content, and it'll pass you back all changes to do OR the complete document. What do you think about this idea?
That's actually what the Visual D semantic server process does.
Lol.
 Syntax highlighting and indenting are done in the plugin, 
 though. These don't need anything more than lexing so far and 
 must be fast.
Isn't there any integrated lexing done by the VS editor component? MD as well as #develop provide simple syntax definitions. But well, semantic type highlighting..yeah, this could be an issue - whereas..this process takes only 1 ms or so in D-IDE, so this shouldn't be a problem.
 Specifying import paths and compile options isn't so easy, 
 because you can have different options for different projects 
 in the solution, meaning the same file might be even used with 
 different settings. That's also one of the points where 
 integration of D_Parser is kind of brittle.
This wouldn't be a problem: There already is a strict separation of global (phobos, tango, vibe.d) and local (project, project-specific include) module sets in the parse cache. As I already said, changes to single documents could be passed to a document 'mirror' in the completion server immediately. Wait, the same file might be used with different settings? Hehe, there actually are no settings for parsing and code completion. Anyway, why should two projects make use of two files? Even if, this wouldn't be any reason to turn mad - the AST was just stored in two parse caches then, so no problem at all :)
Jan 26 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 25/01/2013 13:43, Jacob Carlborg wrote:
 On 2013-01-25 13:01, Bruno Medeiros wrote:

 If I was going with that approach I likely would rather port the MonoD
 parser since it looks just as good, if not better, and C# would be
 easier to port to Java than D.
 But the descent.compiler experience (parser ported from DMD's parser)
 put me off that approach of porting from a parser in another language
 (although the VisualD parser might have less shortcomings than using the
 DMD parser since at least VisualD's parser is designed for IDE use). I
 want to have more control over the parser, and be able to effect my own
 changes in it (something tricky if you're porting - unless you give up
 the porting at some point, and just fork your own version and use ir
 from there)
I didn't say anything about porting :) I was suggesting you integrate the VisualD parser without porting it. That's why I suggested the one in VisualD and not the one in Mono-D.
Ah, fair enough. Yes, that could be an approach, although I dread a bit the thought of having to interface D data to Java through a C API... it might work though if one is carefull and manages to keep the interfacing data simple enough (and leave the complex stuff in their own language realm). But to be honest, the main reason that keeps me from that approach, is that I feel I'm far more productive with Java than with D at the moment. Mostly because not of the language itself, but the excellent IDE semantic functionality, and debugger functionality, that Java has available. So yeah, kinda of a bootstrapping problem. :) -- Bruno Medeiros - Software Engineer
Jan 29 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-29 13:34, Bruno Medeiros wrote:

 Ah, fair enough. Yes, that could be an approach, although I dread a bit
 the thought of having to interface D data to Java through a C API... it
 might work though if one is carefull and manages to keep the interfacing
 data simple enough (and leave the complex stuff in their own language
 realm).

 But to be honest, the main reason that keeps me from that approach, is
 that I feel I'm far more productive with Java than with D at the moment.
 Mostly because not of the language itself, but the excellent IDE
 semantic functionality, and debugger functionality, that Java has
 available. So yeah, kinda of a bootstrapping problem. :)
Hehe, yeah, it's kind of the chicken and egg problem. -- /Jacob Carlborg
Jan 29 2013
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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?
Jan 24 2013
parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
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
Jan 25 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
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
Jan 25 2013