Re: GSoC 2012 -- Elisp backend for Ragel

[Achim Gratz <Stromeko@nexgo.de>]

Aurélien Aptel <aurelien.aptel@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