Hi Robin,
On 30.07.2011 20:07, Robin Lee Powell wrote:
It's interetsing to me that people are making *L*PEG parsers.
What's the advantage there? How are they as a formal system (as
For me, the main advantage can be expressed in two words: simplicity +
PEG - In LPEG actual parser is one short and simple C (or Go or Cython)
routine containing the VM implementation (the match function in
following example):
http://code.google.com/p/pego/source/browse/match.go
From my practical point of view, above main trait gives the following
opportunities:
* VM code can be compiled (to VM asm) in Lua (or Python, or XQuery) and
used with Go engine (like GOLD or programmar but for PEGs and open source).
* Easily extend VM for specific use-cases: For example one can replace
Char matching instructions with regexp instructions and produce small
and fast JS parser engine for in-browser usage.
* incremental/updatable parse trees for use in editors (because one can
reproduce the state of the VM as function of last unaffected node and
resume the VM to parse up something near to diff only).
* Lowering LPEG asm to native code for additional performance (I am sure
that good LLVM expert can complete the task in hours).
Of course - low memory usage and the good speed matters too ;-).
I forgot the main advantage: Combination of simplicity and power makes
LPEG hackable for broad range tasks for the average developer (like me).
opposed to something nice to use)?
I am not in CS, but think that the papers from of Dr.Ierusalimschy and
others are good foundation:
http://www.inf.puc-rio.br/~roberto/docs/peg.pdf
google:puc+rio+lpeg+pdf
Kind regards,
Alek
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg
