Re: [ANN] Lua 5.3.0 (final) now available

[Andrew Starks <andrew.starks@...>]

On Wed, Jan 14, 2015 at 7:26 PM, Tom Sutcliffe <tomsci@me.com> wrote:
> I think we agree, broadly, on the use of errors :) Use them where they are
> appropriate for the control flow of your program, prefer returns likewise in
> places where they make more sense (like when the caller may not want control
> flow interrupted, perhaps it is reasonable to ignore it or do something
> sequentially afterwards even on an unsuccessful return).
>
> Regarding the use of "nil, errstring" only being a convention and not
> something unambiguous in the language, I think that's the price we pay for
> using such a flexible language. It aims to be as non-prescriptive as
> possible, which makes it highly adaptable to all sorts of different uses.
>
> That same flexibility does however work against it in the desktop scenario,
> when using third party libraries that may play a little fast and loose with
> those conventions. For example modules were a bit of a mess in 5.1 because
> every other library seemed to have a different idea about how the module
> convention ought to work. To come back to the error example, it may be that
> library writers err on the side of caution and use returns in their APIs
> where errors might be more appropriate, simply to avoid imposing
> prescriptiveness on the users of the API and therefore be maximally
> flexible, and this leads to situations where it looks like everyone's
> writing code in a sub-optimal style. I don't know, I'm just speculating
> there.
>
> I don't see there's a lot we can do about that without turning Lua into
> something that it's not :) Building things on top of Lua and imposing
> conventions etc on that, well that's fine and exactly what Lua is great at.
> But it's hard to bake any specific style into the language itself, simply
> because the variety of things it's used for is so vast and core Lua
> consequently has to be very generic in some ways.
>
> To take another example of how varied Lua-world is, I'm currently using Lua
> in a project on hardware with 84 kilobytes of available RAM. This was
> shortly after using it on another bit of hardware with 256 megabytes of RAM.
> I also use some of the same code on a PC with 16 gigabytes of RAM. Not every
> approach works perfectly across all those environments :-P
>
> Cheers,
>
> Tom


Tom, this is well said and as non-technical as it is, it put me in a
mind to settle this question for myself.

There are two viewpoints that contrast nicely:

1: Lua provides both `assert` and `error` in its standard library. To
add a third variant that piggy-backs off of the return value amounts
to a feature, even though it is only a "sanctioned idiom." If I cannot
know if a feature is helpful or an annoyance, and I do not need to
have it, then it is probably not worth having, given that all features
limit future options.

2: Lua is a dynamic scripting language. As such, it should rarely ever
crash. Favoring a crash over an uncaught-nil bug is too close to type
checking to be a valid approach in an environment that is dynamic,
wherever possible.

( I regret the hijack of this important thread. :( )

-Andrew