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

[Gavin Wraith <gavin@...>]

In message <CACXZuxfo2igQjUTL-B3cBVjzvhNit8ycn5wM59_y1Rt7_X+Gdw@mail.gmail.com>
          Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:

>On Sun, 25 Nov 2018 at 22:04, Sean Conner <sean@conman.org> wrote:
>>   There are languages that do type inference, where from the context of the
>> code it can determine the type of a variable.

I have always been a fan of Lua, and have great respect for the decisions
made in its development; so a thread like this about what one would like
to remove, add or change is inescapably invidious for me.

I would like to see a reversal of the 'numbers are just numbers' policy;
that is, I would like more of a type barrier between integers and floats
for example. I would like to see
> type (57) --> integer
> type (57.0) --> float
Integers are always needed by the interpreter for its own internal
purposes - the "necessary numbers", but floats, or other number
systems (big numbers, complex numbers, modular arithmetic, ... ) are better suited for libraries, and their suitability is platform dependent - they
are "optional number systems".
I would like to see the type function capable of extension to tables with metatables with a __type index.

With numbers that take arbitrary amount of storage, there is no
avoiding them using heap storage. But with numbers that use a fixed
number of bytes, but more than are required for a value on the stack,
there is a choice: either you bung them in a union type with other
values on the stack, so that a lot of the stack is wasted space, or
you have have an auxiliary stack for them, and every time you push a number
to the auxiliary stack you also push a pointer to it onto the ordinary
stack. There has to be some jargon for this - sorry I do not know it.
There is an obvious space/time tradeoff between the two approaches.
Somebody's thesis somewhere?
The latter has the advantage that it makes for more uniform
handling of optional number systems with fixed size storage.
The auxiliary stack requires no garbage collection, of course.
You might have 32-bit integers internally, and 256-bit bigintegers for cryptographic purposes, for example.

--
Gavin Wraith (gavin@wra1th.plus.com)
Home page: http://www.wra1th.plus.com/