Re: Breakthrough dream

["Pierre Chapuis" <catwell@...>]

March 25, 2017 2:05 PM, "Rodrigo Azevedo" <rodrigoams@gmail.com> 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?

https://github.com/keplerproject/lua-compat-5.3

-- 
Pierre Chapuis