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

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

On Wednesday, January 14, 2015, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> > On 14/01/15 10:22, Roberto Ierusalimschy wrote:
> > >(Sometimes I wonder whether it would be better if the
> > >"nil-message" paradigm was "false-message" instead...)
> >
> > I don't believe that. False is  a value that is a perfectly valid
> > return from a function. Nil is the absence of value, so returning
> > nil means the function could not produce a result. In other words, I
> > need to distinguish between a functio returning the value false, and
> > a function unable to return a value.
>
> The problem is the message after the nil. How can you have a second
> result when you don't have a first one? (This is strongly related
> to the problem of holes in lists.)
>
> If the function was just returning nothing, that would be ok. But
> in fact it is returning an error indicator followed by the error
> message. To mix an error indicator with an absent value is what bothers
> me.
>
> Moreover, some functions can return 'nil' as a "perfectly valid return"
> too. (That is why 'pcall' has an explicit first boolean result.) On the
> other hand, if you go through the libraries, you will see that most
> (all?) functions that return nil-message return only a very specific
> type as a correct result, so they cannot return 'false'. Actually, when
> we use the common idiom 'assert(foo(...))' to change an error indicator
> to an error, we are already assuming that the function cannot return
> false.
>
> -- Roberto

This is exactly why I always error. An error is completely unambiguous and the user can easily decide where (if) they want to handle it. I use errors for timeouts or for any reply other reply that isn't the requested result.

Since I have done this, the amount of fat in my code has decreased significantly. 

-Andrew