 |
lua-l archive |
|
|
||
|
Am 04.03.2014 09:00 schröbte Dirk Laurie:
Is LPeg useful enough to justify how very much larger Lua's C source code will become if it is included? On the other hand, if the Lua implementation itself exploits it for its lexer/parser/VM encoder and its string library, thus demonstrating how useful it can be while at the same time providing some highly instructive well-written LPeg code, the answer is YES!
Making LPeg part of the Lua core (for lexer/parser/VM encoder) and making it a standard library are two different things. The first would mean that you can't remove LPeg if it's unnecessary and/or too big for your taste. Additionally, current LPeg has the limitation that it needs the whole input string for matching, making it difficult to use for the incremental `lua_load()` API. Also, LPeg's flexibility is wasted in the core: the Lua grammar is fixed, so the dynamic interpreter approach is not a good fit in this case (adding macros would reverse that argument, of course).
Personally I wouldn't mind if the standard string matching functions got replaced by LPeg, *but* learning LPeg is harder than learning Lua's pattern matching, and Lua is also targeted at non-programmers, so you probably would want to keep those functions around anyway. Implementing pattern matching on top of LPeg would cost you the ability to remove the LPeg library from your Lua interpreter without removing simple string matching at the same time. And since LPeg is that much larger than Lua's other standard modules, *and* it's aimed at power users, removing it might actually make sense in some cases.
LPeg would make a good standard module, though: It is useful to a lot of people, non-trivial, self-contained, as portable as Lua itself, more or less sandbox-safe, and it can easily be removed from your Lua interpreter if you want to save space.
TL;DR: I'm not a fan of re-implementing the lexer/parser or the string library on top of LPeg.
Philipp