"Trass3r" <u...@known.com> wrote in message news:op.vgejl0zl3nc...@enigma.fem.tu-ilmenau.de... > Nice work! > I'm curious, how does it handle the case of incremental development, i.e. > gradually changing and enhancing the grammar?
The workflow for that is currently like this: 1. Update the ".grm" file (the actual formal grammar). 2. Use GOLD Parser Builder to compile the ".grm" to a ."cgt" (Compiled Grammar Table). I plan to have Goldie be able to do this step itself (via the command-line) in a future version. 3. If you're using "static-style" (see: http://www.semitwist.com/goldiedocs/v0.3/Docs/APIOver/StatVsDyn/ ), then re-run the "StaticLang" tool on the ".cgt" to re-generate the ".d" files. This step isn't needed if you're using "dynamic-style" and loading the ".cgt" and run-time. 4. Update your application code (see the sample app sources: http://www.dsource.org/projects/goldie/browser/tags/v0.3/src/samples ). If you're using "static-style", you will get compile-time errors if your code doesn't match the new grammar. (I you're using "dynamic-style", you'll get bugs. Naturally, static-style is recommended in most cases.) 5. Recompile your program. Also, I've been giving some thought to the idea of automatically generating a function from the grammar that can just simply be filled in, and maybe even do some Visual Studio-style trickery to non-destructively update that function even when you've already filled parts in. We'll see. Any suggestions, of course, would be welcome. One thing I would prefer to avoid though, is going the route of embedding D code directly into the grammar, because that would eliminate what I see as one of the benefits of the GOLD system, which is that grammars are completely independent of implementation/host language. But maybe it could be smuggled in through the comments or something. Or maybe the ".grm" grammar file could even be generated from the D application code. I'll have to think about all of that. If anyone else has any thoughts on any of that, let me know.