[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Breakthrough dream
- From: "Pierre Chapuis" <catwell@...>
- Date: Mon, 27 Mar 2017 08:46:21 +0000
March 25, 2017 2:05 PM, "Rodrigo Azevedo" <firstname.lastname@example.org> wrote:
> 1) an expanded basic library (some batteries), well organized, maintained and documented. "Pure
> Lua" libraries at least.
I agree that we need an organized and well-maintained collection
of pure Lua libraries. I don't think that collection should be
part of the Lua project.
Pure Lua libraries cannot do everything on their own though,
since Lua does not have the required I/O facilities. We need
ways to do two things: network I/O and filesystem manipulation.
Almost anything else can be built on top of that in pure Lua.
There are two approaches to that: low-level libraries such
as luaposix and winapi, or cross-platform libraries like
LuaFilesystem and LuaSocket. I am slightly more in favor of
the second approach.
Slightly related: I wish the standard I/O library would
support Unicode filenames on Windows. I have to patch it
in basically all my professional projects using Lua.
> 2) easy installation on major operating systems (with shared libraries)
Lua is already pretty easy to install everywhere except on
Windows. Because I/O is not standard today, a lot of modules
have C parts so I don't think a Lua development setup without
a C compiler is realistic. There are plenty of solutions that
are not so complicated (MinGW + luawinmulti, the Linux
subsystem, msys2...) but maybe we need something that installs
a local mingw + Lua + LuaRocks with a graphical installer to
satisfy some category of users.
> 3) threads (pthreads!? not Lua's coroutine)
Threads is also something that cannot be done in pure Lua.
I would not be against a standard library for threads,
now the API is not easy to define. I like something like
LuaProc personally. At work we have a pretty good library
to run and manage concurrent Lua processes, sadly we are
not able to open source it as of now.
In any case it should be a library, not a part of the
core language, and remain optional.
> 4) optional type annotations (performance, error check etc)
I know a lot of people in the community like that approach.
Personally, I don't. I like Lua as a simple dynamic language.
Maybe type annotations for functions, especially functions
exported by modules, but I feel this belongs more in something
like LuaCheck than Lua per se.
> 5) easy, transparent, way to port libraries to new versions of Lua.
Something like the lua-compat-* modules?