On Mon, Oct 07, 2019 at 10:24:14PM -0700, Russell Haley wrote:
> On Mon, Oct 7, 2019 at 3:12 PM Egor Skriptunoff <egor.skriptunoff@gmail.com>
> wrote:
>
> > On Mon, Oct 7, 2019 at 10:48 PM Petri Häkkinen wrote:
> >
> >>
> >> > So, the motivation for the change is to move our minds from the
> >> > concept that errors return (nil,msg) to the concept that errors return
> >> > (falsy,msg). Maybe one day in the distant future we might change
> >> > that falsy to false instead of nil.
All this looks like an attempt (or goal) to provide proper exception handling in Lua.
If you think about Lua 6, one goal will be to support real exceptions and exception handlers in the language (i.e. try..catch, and possibly finally using the new "toclose" semantics supported in the VM). In which case we would no longer need to return any fail status explicitly, we would just throw an exception (passing an exception object allocated and initialized in the "try" part, so that no exception would occur to build the error object to throw and that will be caught in a matching catch handler).
The difficulty is to reinforce the typing system for exception types, something that Lua still cannot do cleanly without custom tests (if/elseif or switch) on "typeof" error objects, in a process that can be quite slow and is still not as much optimized as it is in C++. Lua could be inspired by C# (which uses a string typing system) or _javascript_ (which uses a lax dynamic typing system but that can be hinted to considitonally validate the typing system).
Note that if C# has a very strong typing system, this has a cost on the compiler (because ensuring strict type safety is very complex, it's an NP-problem whose resolution rapidly explodes exponentially, and can result in very short programs to hang the compiler with arbitrarily large CPU time/cycles or memory/stack resources needed with lot of contexts needed in stack for backtracking). And C# still cannot assert that a program will not break the engine at runtime or will not cause the program to never halt: systems need then to implement resource monitors and watchdogs to enforce some safe limits, but Lua has still not been designed to behave correctly if resources are exhausted (the lifetime of its allocated resources is not very well managed and its garbage collector and scheduler has many unpredictable behavior when we are near the limits; this forces many systems to drop support for some APIs that cannot be safely rollbacked.)
But may be the simpler model of "structured exception handlers" (as in C and in the windows API) may be implementable without that complexity and without NP-completess for the dynamic typesystem. In which case exception handlers in Lua would not be based on error object types (including inheritance tests) but constant object values (the problem being that it will be difficult to avoid the case of "uncaught exceptions" as applciations would have to document all exceptions that must be caught as part or their own API, and exception thrown by internal APIs used in their implementation. In Java at least there's a worling model that does not require NP-complexity and provides good compile times. In _javascript_, Google designed quite an efficient system for dynamic type inference at runtime, needing low levels of storage, but the dynamic type system of _javascript_ is as simple as it is in Lua, where dynamic type inference is possible to cover at runtime the dynamic type to stronger type system using caches which then become JIT compilable to native code which can be thrown on the dustbiun when no longer needed, and when a derived type is built dynamically from an object, and is not or cannot be compiled, the dynamic evaluation of structured error handlers can still be interpreted instead of being compiled to native code with a strong type system.
