Re: What would you remove from Lua - a case of regression?

[Dibyendu Majumdar <mobile@...>]

On Sun, 25 Nov 2018 at 23:28, Gé Weijers <ge@weijers.org> wrote:
>
> > On Nov 25, 2018, at 09:40, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:

> > So back to only one number type. As you can imagine this would mean
> > add can simply be:
> > a + b
>
> You would still have to do a type check before adding the values,
> because you may be adding a table to nil in stead of two numbers. Why
> not call a runtime system routine that implements the full add
> functionality if the type check fails?

It seems compilers are happier if your code is transparent, i.e.
compiler can see what is going on. The moment you call a function, it
goes into a blackhole so to speak.
You are right that type checks are still needed, But they can of the form:

if (isnum(a) && isnum(b))
  c = a + b
else goto error;
if (isnum(d) && isnum(f))
  e = d / f
else goto error;

The compiler can see what is happening and having a single error
handling block helps too.

> If removing complexity from the language adds complexity to the
> programs written in the language you may be going down the wrong path.
>

There is always a tradeoff otherwise why use Lua? Why not use the most
powerful language available. I am considering whether it is possible
to have a dual VM system, a full featured VM and a cutdown VM,
selectable by user.

> An implementation of “mini Lua” would not be all that useful to me,
> Lua 5.x has just about the right compromise of simplicity and
> expressive power for me, and I can add any missing pieces through the
> C interface. I’m currently using Lua and some custom C code for
> in-house test scripts that interface to prototype hardware, and it’s
> using about 1% of 1 CPU, so a JIT compiler would not be particularly
> useful to have in this case.
>

To be honest as I have posted before Lua's performance is usually
fine; I have not had any issues. But it does seem that LuaJIT has made
people think performance matters. It does maybe in some restricted use
cases where Lua is used almost like a proxy for C. But looking at
JavaScript as an example, performance and JIT compilation has no doubt
been part of the reason for its success. The problem with Lua is how
to achieve the same level of performance while keeping to the 'spirit
of Lua' - i.e. small and beautiful rather than large and ugly
implementation. LuaJIT is one way - and might have been the only way
if the effort to understand and maintain it were in the realms of what
is human.

Regards
Dibyendu