lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

> 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

-- Roberto