[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.0 (final) now available
- From: Andrew Starks <andrew.starks@...>
- Date: Wed, 14 Jan 2015 11:03:14 -0600
On Wednesday, January 14, 2015, Roberto Ierusalimschy <firstname.lastname@example.org> 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
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
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.