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

Scientific apps are very likely to overload operators to work on less limited numeric systems or microstructure semantics than just plus numbers whose precision and value range are unspecified, but also have undesired values that we want to restrict, or when we need more dimensions than just one. This requires developing a new class where all operators will be overridden, even if internally they are implemented with numbers.

Unfortunately we still cannot use any strict integer type in Lua without the cost of IEEE doubles, and Lua is already inconsistent with some number operators like shifts and binary ops which truncate operands to ints but return the result by reconverting it to doubles, looking their initial restriction of range and precision.

As well Lua still does not standardize (like C or C++, or C#, or _javascript_ or Java, or even COBOL, SQL, and RDF) any way to know the limits of its own type system. This creates portability problems. This is a problem also shared by PHP.

Le lun. 26 nov. 2018 à 20:33, Dibyendu Majumdar <mobile@majumdar.org.uk> a écrit :

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.

Yes that is an option that I would like to persue. One problem is
whenever you have return value from a function call you don't know
what the result will be ... so at that point you have to go back to
not knowing the type

The ideal solution is to specialize functions by types. I used to
think the function should be specialized upon entry - but it may make
more sense to specialize at call site. But return values are still a
problem.

>
> > * Eliminate metamethods except for __gc.
>
> I looked over my own code for uses of metatables. I use them extensively
> for userdata, very rarely for tables, and not at all for the other types.
> Furthermore, there are a few methods I've repeatedly used (for both, unless
> otherwise noted):
>
> __mode (table)
> __index
> __newindex
> __tostring (userdata)
> __gc
> __len

Perhaps I should retain these. Certainly I intend to get rid of the
arithmetic operators to start with.

> > Now, I do not know how often people implement operator overloading -
> > but given some languages do not have this feature it may not be a big
> > loss.
>
> Personally, almost never. But I do use LPeg (a lot) and that does use
> operator overloading. And again, for me, this would be a big loss.
>

Yes LPeg is one of the heavy users of operator overloading.

> > I personally can do without coroutines too, I am not sure how widely
> > they are used; but the trade off is that we eliminate a bunch of
> > complexity from mini Lua.
>
> I use them. Maybe not as often as LPeg, but in the context I use them,
> they are invaluable. I use coroutines to implement servers.

I think it would be nice to have two VMs built-in - a full featured
one and a cut-down one, with user being able to choose the one they
want to use. But it is harder to switch between dual number type to a
single number type.

Thanks for the feedback.

Regards
Dibyendu