Aurélien Aptel <aurelien.ap...@gmail.com> writes: >> 2) It adds yet more SOUP (software of unknown provenance) to the build >> process which may then need mitigating against (this is relevant to me, >> although possibly not to Org-mode). > > You mean it complicates the build process? I'm not sure I understand.
It needs yet another tool to fully build org-mode from scratch, which needs to be installed, bug-free and configured correctly. Right now all one really needs to have to build org-mode is a working Emacs (even make is optional). >> 3) FSM implementation into code is inherently very simple anyway > > Well I've never done it for big language but I did not find it that > easy. Mistakes are easily made e.g. you end up accepting more thing > that the language does in order to simplify the code, etc. Which is just as easily done by specifying the syntax incorrectly. >> What I do instead is validate the FSM code against the formal state >> representation as an integration test (which is fairly easy to arrange). > > I'm not familiar with this. Does this mean you test random valid and > invalid input against the parser (aka fuzzing)? No, you can (for a suitably restricted set of languages) formally proof that the implementation and the specification is identical for any input. > I'm not very experienced (just a student :) but for me their > usefulness is in the robustness and the abstraction it brings. It also > happens to be faster. But I see what you're saying. The assumption that an FSM running in ELisp is faster than a bunch of regexp has not been actually tested or has it? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
