Re: no return value vs. nil return value(s)

[Lorenzo Donati <lorenzodonatibz@...>]

On 11/09/2011 23.38, Dirk Laurie wrote:
[...]
> The simple, clear idea in Lua is that when the calling routine tries to
> retrieve a value not returned, you get `nil` instead of an error message.
>
> I can't believe that the Lua team intended the programmer to write code
> which relies on a distinction between two or more of the cases:
>
>   -  `end` (matching `function`) reached
>   -  `return`
>   -  `return nil`
>   -  `return a,b,c` when a,b,c all happen to be nil
>
> Such code should not be expected to work, even though in practice it might.
>
> In general, any artifact which can be exposed only by a library routine and
> is not explicitly documented, probably is not planned to be a feature
> exploitable by the programmer.
Yes, that's the same feeling I have by default. But the idea to exploit 
such a feature came to me just from the behaviour of some library 
functions, which *do* make a difference:

--------------------------------------------
local function f() return end
local function g() return nil end

assert( f() )  --> bad argument #1 to 'assert' (value expected)
assert( g() )  --> assertion failed!


local t = {}

table.insert( t, f() )  --> wrong number of arguments to 'insert'
table.insert( t, g() )  -->ok
--------------------------------------------

So even if I agree it is a subtle difference, the fact that the 
difference is exposed through the library seems to suggest that it is a 
legitimate technique.

This idea was also reinforced by this old thread [1], in which it seems 
that Lua authors consider the behaviour legitimate [2].

[1] http://lua-users.org/lists/lua-l/2011-02/msg01444.html
[2] http://lua-users.org/lists/lua-l/2011-02/msg01445.html

Sadly I cannot find the other thread implicitly cited in [2] and I don't 
remember the details.

So that's the source of my confusion: is it a legitimate technique 
(albeit something subtle, and so to be used with a grain of salt where 
it makes sense [3]), or is it an implementation detail on which no 
correct program could be based?


> In this case, I'm happy with the manual not laboring the point.  Lua was not
> designed by Nicolas Bourbaki, thankfully, and its manual (though confessing
> to be dry in places) does not read like “Éléments de Mathématique”.
Well, I didn't have the pleasure (is it?) to give a look at that 
collection of writings, but I admit, if this is what you mean, that a 
collectively written refman probably won't be particularly better for 
coherence and readability. Nevertheless I always hope that by these 
discussion on readability Lua team could get something useful to improve 
its "dry areas".

A very nice person recently told me:

"A good reader is any writer's friend... a critical reader is a writer's 
ally." :-)

Cheers.
-- Lorenzo.

> Dirk

[3] The case where it may make sense is the following: an higher level 
function that does a table traversal and calls the function "func" on 
every entry. "func" will return either: (1) a new value for the entry, 
(2) nil to clear the entry, or (3) nothing to leave the entry as it is.

I know that I could devise a different protocol easily, but that seemed 
very clean and intuitive, and could make "func" (which is defined by the 
client) simpler.

Of course all this is moot if nil vs. nothing is an implementation detail.