help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to use parsing expressing grammar


From: Mike Mattie
Subject: Re: how to use parsing expressing grammar
Date: Wed, 4 Mar 2009 22:18:51 -0800

On Tue, 03 Mar 2009 23:52:25 +0000
W Dan Meyer <specuu@gmail.com> wrote:

> Xah Lee <xahlee@gmail.com> writes:
> 
> > On Mar 3, 9:59 am, Mike Mattie <codermat...@gmail.com> wrote:
> >> On Tue, 03 Mar 2009 17:34:41 +0000
> >>
> >> Leo <sdl....@gmail.com> 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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]