From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Fran=C3=A7ois_Pinard?= Subject: Re: Parsing Org-mode in Python Date: Mon, 06 Jan 2014 21:33:23 -0500 Message-ID: <87txdg34i4.fsf@iro.umontreal.ca> References: <2013-11-22T17-28-29@devnull.Karl-Voit.at> <3414130.xOGDSAomuL@descartes> <2013-11-22T17-57-08@devnull.Karl-Voit.at> <81482742.cUeHUGJmrV@descartes> <2013-11-24T13-29-07@devnull.Karl-Voit.at> <878uuvssi8.fsf@bzg.ath.cx> <87fvp3snof.fsf@iro.umontreal.ca> <87zjnaidlz.wl%n142857@gmail.com> <2014-01-06T11-23-40@devnull.Karl-Voit.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0MTz-0000sS-CQ for emacs-orgmode@gnu.org; Mon, 06 Jan 2014 21:33:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0MTs-0007dw-Kx for emacs-orgmode@gnu.org; Mon, 06 Jan 2014 21:33:31 -0500 Received: from 206-248-137-202.dsl.teksavvy.com ([206.248.137.202]:57670 helo=mercure.progiciels-bpi.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0MTs-0007df-Fj for emacs-orgmode@gnu.org; Mon, 06 Jan 2014 21:33:24 -0500 In-Reply-To: <2014-01-06T11-23-40@devnull.Karl-Voit.at> (Karl Voit's message of "Mon, 6 Jan 2014 11:44:40 +0100") 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 Karl Voit writes: > I did not get the impression that [ply] is a parsing engine that is > done the Python way. PLY has pros and cons. SPARK[1] always attracted me as being more elegant. While it accepts a wider set of grammars than PLY, SPARK can become quite slow on grammars which are less "natural" (admittedly a very fuzzy, subjective term). For simpler grammars, recursive descent does the job at good enough speed, and often, grammars can be rearranged a bit so the lexer could cleverly help the parser. Of course, it looks like more work writing a recursive descent parser, yet many times in my experience, the programmer is amply repaid with simplicity and clarity. >> You don't need a Lisp interpreter written in Python, only Python >> code that understands org syntax without getting confused. > if you are going to use a ELISP interpreter to parse Org-mode syntax > for Python, this should completely re-use the original Org-parser and > nothing else. I have no idea if this is possible or not. If you have > to implement a parser on your own, you probably should stick to > Python-only. Hey hey, it's fun! :-) You misunderstood me, but this is constructive actually, as you raise good points. In my dreams, a pure Python parser parses Org mode files. However, here and there in the parsed files, as data, we can see bits of Emacs Lisp code, or even Calc syntax at some places. That Emacs Lisp code could be mere constants or identifiers, but sometimes more complex, evalable S-expressions. A parser is probably of limited use if it does not come with some extra-tools covering most frequent use cases around the syntax, and I guess that pressure will develop to have some kind of Emacs Lisp interpreter, hardly complete, probably only mild or even ridiculous. The interesting idea in your comments is that, *if* we had an Emacs Lisp interpreter of serious quality, that interpreter could use "the original Org-parser and nothing else". That would solve maintenance, as the parser would be wholly external, to be found in Org mode distribution, all standard. But this avenue is quite unlikely: it looks like a major undertaking to me, and while such a parser would be useful on small data excerpts within an Org file, it might be inordinately slow if it had to interpret a lot of Lisp code while deciphering big Org files. Worse, keeping a Python parser in sync with the true Emacs Lisp parser would require much energy, maybe only once in a while, but extended over a long period of time. Unless a great enthusiasm exists, distributed on many people, such projects are always doomed to fail. Not many people are ready to commit themselves for life in the required maintenance. Fran=C3=A7ois --------------- [1] http://pages.cpsc.ucalgary.ca/~aycock/spark/