 |
lua-l archive |
|
|
||
|
On 30/09/2018 19:25, Jim wrote:
On 9/29/18, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:that's /by design/. The goal was/is to keep Lua size small. I can't say if implementing alternation (i.e. that OR operator) will increase Lua size by much, but I suspect it will.how comes that squirrel has them ? does that make squirrel NOT small ? or has that more to do with it being written in c++ ? (which was an unnecessary mistake imo)
I don't know squirrel, so I can't say. Anyway, did you compare the size (both source and executable) of Lua with those of squirrel?
If squirrel can implement a full regex engine in less space than Lua, it could be worth pointing that out to Lua team.
On the other hand I suspect squirrel regex engine may be implemented using C++ regex classes, so the implementation could be very terse in squirrel source. Moreover even executable size could be smaller because the object code of the C++ regex engine could reside in some system/platform DLL, if not linked statically into the squirrel interpreter.
Keep in mind that Lua is written in very portable C (almost all C89, some few parts C99) and its pattern facility is built into the source, so it can be compiled on any system with a barebone C compiler. Lua /can/ be compiled as C++, but it doesn't use any C++ library facility that is not also in a C library.
If squirrel regex implementation relies on C++-specific libraries, comparing it to Lua is not actually fair: you should compare it against Lua /together with/ a regex engine binding, like a PCRE binding, instead.
btw: squirrel separated the interpreter and its std libs into 2 different c libs which looks like a good idea to me.
If you really don't need some Lua library you can compile a version of Lua interpreter disabling some of them. The fact that this is not done by default at the Lua code level seen by the interpreter depends on the fact that Lua is primarily an engine to be embedded in some custom C code, the so called "C application" (this is by design). So a C programmer can choose which library to include in the compilation anyway.
Moreover, if Lua is compiled as a DLL on a PC-class machine, the C application can be small by simply linking to Lua dynamically.
If you really need Lua code statically linked to your C code, then you can customize what parts of Lua you really need anyway.
The standard interpreter is just a very lightweight C application that happens to embed a Lua engine. Lua "the language" wasn't designed to be run only in the context of a command line interpreter.