Re: [O] GSoC 2012 -- Elisp backend for Ragel

[Martyn Jago]

Hi, and welcome Aurélien,

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Aurélien Aptel <address@hidden> writes:
>
>> On Sun, Mar 25, 2012 at 6:17 AM, Rustom Mody <address@hidden> wrote:
>>> FYI, there is already an elisp Org parser being worked on in development
>>> branch of Org mode. It isn't finished yet, but still advanced enough so
>>> a generic exporter could be built upon it.
>>
>>> Is there any interest in ignoring it and restart all the work from
>>> scratch?
>>>
>>> Yes I agree, no point redoing work unnecessarily.  Maybe the optimal
>>> solution would be for Aurélien to work with Nicolas and Adrian to minimize
>>> useless rework?
>>
>> Regardless of the org-mode parser, I think I should work on the elisp
>> backend for ragel which is something that can benefit any elisp
>> project.
>
> Certainly.
>
>> As for the new org-mode parser, I could not find it on the repo. Could
>> you point me to the relevant files?
>
> See org-element.el in contrib/ directory.  You need development version.
>
>> Is it still hand written? 
>
> Yes.
>
>> If so, I think it's ultimately a bad idea and it should be rewritten
>> using ragel.
>
> It may be. But it allows for flexibility. Org's syntax is evolving, and
> I consider org-element.el as a parser, but also as a guidance in that
> process. Since there is no formal description for Org syntax yet, an
> org-element.el is more useful than a full-blown parser generator for
> now.
>
> I don't know ragel (save for a short excursion in its website), but I'm
> pretty sure that even if it generates elisp code without dependency, any
> evolution to Org syntax will require to use it again. At that time, it
> may be difficult to find someone able and willing to undertake that
> updating task in a reasonable delay (since we're talking about a core
> feature). On the other hand, there are quite a few elisp hackers in
> Emacs's world.
>
> Now, if ragel can improve org-element.el while preserving its
> flexibility (and a compatible output, since I assume you won't also
> rewrite the generic export engine), I'm all ears.

I am a big fan of formalizing as much state design as possible into
formal state-machines, and have been for some time.

For the design process I currently use the excellent plantuml library
from within Org-mode (Aurélien, see lisp/ob-plantuml.el for the
Org-babel interface), although have previously used a bespoke
Ruby/Graphviz library of my design, and previous to that Ragel.

For that reason I think it would be great to see an `Org-Babel'
implementation of Ragel. I think it could be a very useful tool.

However, I don't use code auto-generation by Ragel and the like for the
following reasons...

 1) It complicates the build process
 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). 
 3) FSM implementation into code is inherently very simple anyway

What I do instead is validate the FSM code against the formal state
representation as an integration test (which is fairly easy to arrange).

So my point is, I personally don't see the use of FSM code generators as
a panacea to perfect super-fast code. To me their usefulness is in the
visual representation of the state interaction (during development, and
subsequent code documentation), and the resulting code quality.

Just my 10c

Best, Martyn

>
>
> Regards,