On Tue, 03 Mar 2009 23:52:25 +0000 W Dan Meyer wrote: > Xah Lee writes: > > > On Mar 3, 9:59 am, Mike Mattie wrote: > >> On Tue, 03 Mar 2009 17:34:41 +0000 > >> > >> Leo wrote: > >> > On 2008-12-21 09:49 +0000, Helmut Eller wrote: > >> > >> I'm pretty sure if you create it, more and more people will > >> > >> join it. I'm very interested in PEG and think it is of > >> > >> critical importance. > >> > >> > > I'll try to set up project at savannah. > >> > >> > I have seen the project on > >> >http://savannah.nongnu.org/projects/emacs-peg. I wonder it might > >> >be a > >> > good idea to make a newsgroup on gmane to link to the mailing > >> > list. It will make more Emacs users subscribe to it. > >> > >> > Best wishes, > >> > >> I was working on a PEG/CFG parser > >> compiler:http://www.emacswiki.org/cgi-bin/wiki/ParserCompiler > >> > >> I will be resuming the development soon. Please keep me in the > >> loop on such efforts. > > Are we talking about memoising PEG (e.g Packrat) in elisp? There > might be more people interested. I do realise that Emacs doesn't > have decent parsing facility and it makes it's regular expression > based engine in more complex areas useless (mentioned nested tags). > Since it's automata based you cannot go beyond simple patterns. That > means also that everybody is reinventing a wheel with implanting all > those recursive decent parsers when it comes to analyse, pretty > print, syntax highlight of such modes like Haskell one. Packrat > parser is the best option out there currently because it recognises > much complex grammar then LALR(1), and it has no ambiguities with > expressing these grammars. Works well also as a standalone combinator > based solution rather then a parser generator, plus it is lex-less > e.g allow to recognise several different languages in _one_go_ and > one context without marking them explicitly! cheers Dan W Yes, packrat PEG. I am currently working on the left recursion, and the memoization. The code generator is done. It is still very alpha, and a vehicle for experimenting, but it is also the third iteration. I want to make it useful first, which requires a number of features, and then try some more exotic things. The design goal is to produce a parser compiler that is easy to use. There are many tasks, or good projects in Emacs that would be far easier to solve with a parser. It is implemented as a macro so that you can go from from grammer to parser is a single eval. There is a direct correlation between the grammar and the AST produced in simple grammars. With these two features you can quickly put together a parser to glue various jobs together. It will be complete too so you aren't handicapped in complex grammars. Beyond that I want to implement more before I venture on where the design can go. What I don't expect is parsing large volumes of data such as the linux kernel tree at reasonable speed. Maybe it will, For that I would expect to port it outside of elisp. I won't give timelines, but I have more time than before (0) to work on it now. Cheers, Mike Mattie