Re: Breakthrough dream

On 26 Mar 2017, at 06:54, Egor Skriptunoff <egor.skriptunoff@gmail.com> wrote:

On Sat, Mar 25, 2017 at 10:26 PM, Dirk Laurie wrote:
2017-03-25 15:04 GMT+02:00 Rodrigo Azevedo:

> Based on the thread 'Selenophobia', and your major experience, choose 5
> characteristics you think indispensable to keep Lua advancing as a
> "general-purpose script language";
>
> 1) an expanded basic library (some batteries), well organized, maintained
> and documented. "Pure Lua" libraries at least.
> 2) easy installation on major operating systems (with shared libraries)
> 3) threads (pthreads!? not Lua's coroutine)
> 4) optional type annotations (performance, error check etc)
> 5) easy, transparent, way to port libraries to new versions of Lua.
>
> Is this possible to start, organize and support for a long period ( a
> 'larger' community)?

This does sound a bit like someone who wishes to enlarge the listening
public of a radio station that broadcasts classical music, and comes
with suggestions like:

* breezy disc jockeys
* short, snappy pieces instead of those interminable symphonies
* phone-in discussion programmes
* jazz is fine music too, isn't it?

The analogy with classical music is very incorrect.
All 5 characteristics being discussed here would be useful for all Lua users.
They are not contradictory to set of features we already have in the language.

All of these extra things have costs that I am not willing to pay, especially (1) and (3). I think it would help to make the distinction between the language runtime and a distribution. I think the runtime should stay as it is because it is small and easy to embed in other programs.

Distributions are another matter, and should come Batteries-Included. I enjoy playing around with Codea on my iPad, and Löve on my laptop, and I'm all in favour of people making more of these or supporting the existing ones. I think the distinction here is between the Linux kernel and the distributions like Ubuntu, RedHat, etc. This would solve (1) and (2) without any change to Lua.

Under no circumstances should threads ever be added to the Lua runtime. It would essentially make the runtime un-embeddable. The only real use I can think of for threads is Workers, and this should be a library. This addresses (3).

Type annotations and optimisations would make the embedded compiler too large. I think there is certainly merit in having an optimising compiler as a separate project, and it would be nice if it was supported by the core Lua team, but obviously they have their own priorities. Essentially, we need a llvm compiler that takes Lua Source and outputs Lua ByteCode. The only cooperation required from the core Lua team would be an agreement on some syntax that can be used for annotations which would be ignored by the embedded compiler. This could be a marked up comment, but it would be nicer to have something separate. I have some small annotations I use with a modified compiler and I use '<anno>'. This could then integrate with LuaCheck and some DBC mechanism as well. This solves (4).

I've got nothing for (5). The looseness of version compatibility and the prevalence of undefined behaviour makes this almost impossible to solve at this stage in any strict way.

So, apart from agreed syntax for annotations, I think everything else should be solved by the community and not involve changes to the core language.

Regards,

Duane.