[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Being constructive [Was: Nit-picking]
From: |
Mike Mattie |
Subject: |
Re: Being constructive [Was: Nit-picking] |
Date: |
Sat, 12 Apr 2008 14:38:33 -0700 |
On Sat, 12 Apr 2008 11:46:11 +0000
Alan Mackenzie <address@hidden> wrote:
> Hi, Eli!
>
> On Sat Apr 12, 2008 at 01:30:27PM +0300, Eli Zaretskii wrote:
>
> > [Moving this to emacs-devel, where it belongs.]
>
[snip]
> I think it would be psychologically very uplifting for each of us to
> post, in a constructive non contentious fashion, what we are working
> on, what we are trying to achieve, and so on. This was exactly what
> my previous post was meant to be. Eli, could you possibly respond
> again to that last post with a summary of what _you_ are working on?
> We could develop a very positive constructive thread from this. :-)
>
I am working on a Parser Compiler that generates pure elisp parsers from
a macro DSL.
http://www.emacswiki.org/cgi-bin/emacs-en/ParserCompiler
There are many times when a regex has turned into a ad-hoc parser. My
goal is to make those small to medium size parsers compact and declarative.
I think it is very useful considering the Emacs design of using co-processes
for everything external. That's alot of small parsing jobs to hook up
some simple and not so simple tools.
The architecture of the design is unique: the compiler itself is
programmable reducing the need for call-outs to handle the parts
of the grammar beyond the scope of the usual meta-operators.
There is often a claim that open-source chases head-lights but
this design for better or worse is unique. It's baking on
EmacsWiki while I evaluate it's properties.
For example if PEG and CFG are called grammar "classes" in the logical
sense it will be possible to mix those classes along with a grammar
specific class (user defined) with well defined behavior. That is
unique AFAIK (please cite related works if you know where this has
been done before).
When it is completed I will likely port it to mzScheme to compare
it against the performance of standard designs, and evaluate how
the design is expressed when I don't have to kludge abstraction
facilities such as co-routines. I will always maintain the elisp
version though because Emacs is always with me :)
It won't hit 0.1.0 until left-recursion is solved eliminating the
possibility of user defined infinite loops.
Currently it works well with right-recursive grammars, builds canonical
AST trees, and the code emitted looks like I wrote it by hand - the back-end
folds emitted elisp to take advantage of special forms that can be shared.
When it hit's 0.1.0 I'll post a mention again and submit it to ELPA.
It's my thank-you note to the Emacs community. If some-one wants to write
a counter thank-you note Elisp TCO is at the top of my elisp wish-list.
Cheers,
Mike Mattie
signature.asc
Description: PGP signature
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, (continued)
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Richard Stallman, 2008/04/11
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Richard Stallman, 2008/04/11
- Re: Nit-picking (was: 23.0.60; M-( and M-) should not be bound in ESC map), Eli Zaretskii, 2008/04/12
- Re: Nit-picking, Alan Mackenzie, 2008/04/12
- Re: Nit-picking, Eli Zaretskii, 2008/04/12
- Being constructive [Was: Nit-picking], Alan Mackenzie, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Eli Zaretskii, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Jason Rumney, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Eli Zaretskii, 2008/04/12
- Re: Being constructive [Was: Nit-picking], Eli Zaretskii, 2008/04/12
- Re: Being constructive [Was: Nit-picking],
Mike Mattie <=
- RE: 23.0.60; M-( and M-) should not be bound in ESC map, Drew Adams, 2008/04/12
- Re: 23.0.60; M-( and M-) should not be bound in ESC map, Richard Stallman, 2008/04/12