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

[Graham Wakefield <wakefield@...>]

It's a good reminder to avoid the common habit of converting code like this:

local v = somefunction()
anotherfunction(v)

into 

anotherfunction(somefunction(v))

The latter former always passes a known number of values (i.e., one) to anotherfunction(). The latter passes an entirely unknown number of values to it, possibly none.

On Sep 11, 2011, at 4:12 PM, Lorenzo Donati wrote:

> 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.
> 
> 
> 
>