Re: OR, quantifier support in Lua patterns

[Jim <djvaios@...>]

On 10/1/18, Lorenzo Donati <lorenzodonatibz@tiscali.it> wrote:
> 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?
well, yes, squirrel(-lang.org) is in deed bigger:
static libs:
interpreter/vm lib:
-rw-r--r-- 1 root root 523K May 27  2016 /usr/local/lib/libsquirrel_static.a
its std lib (which is in a separate lib):
rw-r--r-- 1 root root 138K May 27  2016 /usr/local/lib/libsqstdlib_static.a
vs:
-rw-r--r-- 1 root root 423K Jul 24 22:52 /usr/local/lib64/liblua.a
for lua interpreter + stdlib

binaries:
-rwxr-xr-x 1 root root  20K May 27  2016 /usr/local/bin/sq*
-rwxr-xr-x 1 root root 415K May 27  2016 /usr/local/bin/sq_static*
(the interpreter/vm bin is also used for compiling bytecode, no
separate binary necessary)

vs lua:
-rwxr-xr-x 1 root root 213K Jul 24 22:14 /usr/local/bin/lua*
-rwxr-xr-x 1 root root 144K Jul 24 22:14 /usr/local/bin/luac*

> 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.
in deed, i have not considered this as i am no c++ user and try to avoid
the crap at all costs, but under windows heavy usage of c++ seems to be
the norm.

but the squirrel author has implemented a "tiny regex lib" in ansi C
(T-Rex is a minimalistic regular expression library written in ANSI C)
because he "couldn't find any free regular expression library that wasn't huge
and bloated, while most of the time he needed just basic functionalities"
as he wrote on
http://www.demichelis.net/default.aspx?content=projects&template=projects

a quick look into the squirrel sources reveals that he has implemented the
squirrel regex functions in sqstdlib/sqstdrex.cpp (663 lines) in procedural
c style without use of any c++ stdlib regex helper classes.

so does that really bloat and make squirrel BIG in any way ?
or is it just the usual cheap excuse as in "we cant bloat lua with binary/octal
integer literals" (which anyone else has of course) but have hex
integer literals,
since it does NOT bloat the language in any way and can't be done with
tonumber().

i am really tired of always the same lamenting.
we would not use lua if we had not already written thousands of lines
of binding
c code (which was a very stupid decision we bitterly regret by now).
the only reason that stopped us from using squirrel in the first place was
that is written in c++ (with all the dependencies that introduces
without any gain).
if squirrel could be rewritten in c we would use it instantly and port
all the c binding
code to it.

the squirrel c api is also much better designed.

> 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.
well, the usual  lamento.
on unix you get posix regex and LOTS of other useful functions for FREE
by the c lib (which you have to use anyway) or as direct syscalls.

when building via "make linux" (for instance) you know what platform is used
and what it offers (at least std posix functions).
(you can also check feature macros if you prefer)
so instead of linking against big bloated crap like libreadline use what's
already in the c lib for FREE.

that could provide a table "regex" (or "re") that makes use of the c lib's
extended posix regex (which has to be there as required by the posix std.
btw: are the c++ std regex classes implemented using this c lib support ?)

there should be also a table "posix" (or "unix" or just "sys") that contains the
std posix functions (like chdir, mkdir, setenv and the like) and is a
metatable of
the "os" table.

that "posix" table should also have the metatable "linux" on Linux which should
contain Linux-only bindings (similar on freebsd, solaris etc)

> If squirrel regex implementation relies on C++-specific libraries,
which is not the case.

> 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.
> 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.
i totally understand that, but having above additional tables does not cost much
and should also be provided with the possibility of disabling them when they are
not needed (or even harmful) analogous to the tables/modules Lua
already provides.