why not use more functionality already provided by the posix standard libc ?

classic Classic list List threaded Threaded
3 messages Options
Jim
Reply | Threaded
Open this post in threaded view
|

why not use more functionality already provided by the posix standard libc ?

Jim
On 5/10/19, Sean Conner <[hidden email]> wrote:
> There are at least three modules providing regex in Lua available via
> LuaRocks: Lrexlib-POSIX, Lrexlib-PCRE (most popular) and Lrexlib-PCRE2.
> There's also at least two POSIX modules: lposix and luaposix (most popular).
> There *is* a solution, it's just not a built-in one.

see ? this is exactly the problem, Sir.
everybody reinvents the wheel again and again instead of combining
efforts and put a decent solution into the Lua std lib for FREE,
i. e. add such functionality to the "os" table where it in fact belongs.

Reply | Threaded
Open this post in threaded view
|

Re: why not use more functionality already provided by the posix standard libc ?

Dirk Laurie-2
Op Sa. 11 Mei 2019 om 09:12 het Jim <[hidden email]> geskryf:

>
> On 5/10/19, Sean Conner <[hidden email]> wrote:
> > There are at least three modules providing regex in Lua available via
> > LuaRocks: Lrexlib-POSIX, Lrexlib-PCRE (most popular) and Lrexlib-PCRE2.
> > There's also at least two POSIX modules: lposix and luaposix (most popular).
> > There *is* a solution, it's just not a built-in one.
>
> see ? this is exactly the problem, Sir.
> everybody reinvents the wheel again and again instead of combining
> efforts and put a decent solution into the Lua std lib for FREE,

That's Lua users for you. They love reinventing the wheel. Mind you,
sometimes they come up with shiny mags fitted with Pirellis.

> i. e. add such functionality to the "os" table where it in fact belongs.

In the case of regex, it belongs in the string library, but I don't
support pulling in regex. It is a an old-fashioned, human-unfriendly
solution to a simplified string matching problem. Its only advantage
is that many non-Lua people already have a love-hate relationship with
it.

The Lua solution is two-pronged:
(a) for everyday use, the string matching library is concise and easy;
(b) for complex parsing-type applications, load LPEG. Besides being a
Lua-ish extension, it is more powerful than regex.

Reply | Threaded
Open this post in threaded view
|

Re: why not use more functionality already provided by the posix standard libc ?

Sean Conner
In reply to this post by Jim
It was thus said that the Great Jim once stated:

> On 5/10/19, Sean Conner <[hidden email]> wrote:
> > There are at least three modules providing regex in Lua available via
> > LuaRocks: Lrexlib-POSIX, Lrexlib-PCRE (most popular) and Lrexlib-PCRE2.
> > There's also at least two POSIX modules: lposix and luaposix (most popular).
> > There *is* a solution, it's just not a built-in one.
>
> see ? this is exactly the problem, Sir.
> everybody reinvents the wheel again and again instead of combining
> efforts and put a decent solution into the Lua std lib for FREE,
> i. e. add such functionality to the "os" table where it in fact belongs.

  You might find it interesting to read this thread from September of 2016:

        http://lua-users.org/lists/lua-l/2016-09/msg00088.html

Some hightlights:  I go over potential difficulties in just enumerating
entries in a directory:

        http://lua-users.org/lists/lua-l/2016-09/msg00107.html

Some follow-up messages to that include the difficulties of enumerating
directories in Android and iOS (both systems Lua can run on):

        http://lua-users.org/lists/lua-l/2016-09/msg00123.html

or the lack of directories on Nucleus OS:

        http://lua-users.org/lists/lua-l/2016-09/msg00106.html

In this message:

        http://lua-users.org/lists/lua-l/2016-09/msg00089.html

Daurnimator links to this page:
       
        http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/

which is about Python's standard libraries and how they've stagnated. Steve
Litt suggested people step up and do a community curated, approved and
documented library:

        http://lua-users.org/lists/lua-l/2016-09/msg00099.html

but alas, no one stepped up (and this has been suggested several times in
fact).

  But the final word comes from Roberto:

        These are two sides of the same coin. They are left out because we
        find that an extra bother because they are not part of ISO C. Not
        being part of the standard makes them more bother to implement, more
        bother to test, more bother from people asking for new platforms,
        more bother for people asking for platform-specific options [see the
        list right now], etc. ISO C gives us a clear line where to stop.

        http://lua-users.org/lists/lua-l/2016-09/msg00115.html

  So my proposal follows Steve Litt's---come up with the missing functions,
package them up into a module and *SHOVE THEM DOWN THE COMMUNITY'S THROAT TO
USE THEM TO THE EXCLUSION OF ALL OTHER MODULES* and maybe then we can have
only one way to do it.  While making sure it works for not only POSIX but
Windows as well (and screw the other systems Lua runs on because they don't
count, right?)

  -spc ("All abstractions leak."  -- Joel Spolsky)