lua-users home
lua-l archive

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

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


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." :-)

-- Lorenzo.


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