 |
lua-l archive |
|
|
||
|
On 04/12/2012 14:03, Rena wrote:
On Tue, Dec 4, 2012 at 7:59 AM, steve donovan <steve.j.donovan@gmail.com> wrote:On Tue, Dec 4, 2012 at 2:40 PM, spir <denis.spir@gmail.com> wrote:One more point for genuine bools ;-) (hum...)One of my most common errors is to say 'if foo then ... end' when I _really_ mean 'if foo==nil then .. end'. Kind people then write to me to ask why I am so prejudiced against genuine false values. But still, just because it's a common sloppy mistake, does not mean that the language itself must make it impossible to be sloppy. steve d.I write "if foo then" all the time, in cases where foo should never be false anyway, but may be nil, or vice-versa. If it ever is, then something's wrong elsewhere, and neither treatment can be considered correct.
I take the opportunity to ask about a point I have in mind for a few days.I like very much (in Lua only) the idiom consisting in return nil + error instead of throwing an error. I think it fits the language in making more fluid code.
How can we adapt that to boolean-product funcs? (eg is_subset(s1, s2)) Clear it would be rather error-prone to return nil...
DenisPS: The more I think at it, the more imposes itself the idea we need 2 nils: one "nullnil" for required data, meaning a real error, "too bad, missing, try again another day"; one "nonenil" for optional data, thus just meaning "not there!". The first one could not play the role of a boolean, maybe not even explicitely assigned (only be written out for programmer feedback), but it would the perfect as (often implicit) return value meaning error. We want to be able to play with nil because of the second role (semantic), a placeholder for optional data, but this opens the door to messing up with the first role (so-to-say linguistic); the first role is Lua meaning, the second finds meaning from our apps.