From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martyn Jago Subject: Re: GSoC 2012 -- Elisp backend for Ragel Date: Sun, 25 Mar 2012 13:52:02 +0100 Message-ID: References: <87vclsykl6.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:41185) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBmvj-0003Ih-2G for emacs-orgmode@gnu.org; Sun, 25 Mar 2012 08:52:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SBmvh-0005QY-1A for emacs-orgmode@gnu.org; Sun, 25 Mar 2012 08:52:18 -0400 Received: from plane.gmane.org ([80.91.229.3]:46029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SBmvg-0005Me-NH for emacs-orgmode@gnu.org; Sun, 25 Mar 2012 08:52:16 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SBmve-0003gR-De for emacs-orgmode@gnu.org; Sun, 25 Mar 2012 14:52:14 +0200 Received: from 88-96-171-142.dsl.zen.co.uk ([88.96.171.142]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Mar 2012 14:52:14 +0200 Received: from martyn.jago by 88-96-171-142.dsl.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 25 Mar 2012 14:52:14 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi, and welcome Aurélien, Nicolas Goaziou writes: > Hello, > > Aurélien Aptel writes: > >> On Sun, Mar 25, 2012 at 6:17 AM, Rustom Mody 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,