On Mon, 15 Sep 2014, Michail Vidiassov wrote:

Dear Peter,

...

More a lua design decision. 'nil' is equal to 'false' here

I know no CS theory behind lua design, but try this: \starttext \startluacode if nil == false then io.write("nil == false\n") end if nil ~= false then io.write("nil ~= false\n") end \stopluacode TEST \stoptext

and get

nil ~= false

I think that what Peter meant was: if nil then .... end if not nil then ... end Aditya

On 9/15/2014 6:12 PM, Michail Vidiassov wrote:

Dear Aditya, Peter and All,

...

I think that what Peter meant was:

the real issue is not teaching me lua and improving the style of my example, but my complaint (correct or not) about inability of lpdf.checkedkey

it looks like your question was not clear then

to correctly fetch false boolean values: they are fetched as nil, just as if they were absent or of incorrect type.

well, they're just not treated special

Please, someone with time and, preferably, authority - take a look at lpdf.checkedkey code (5 minutes maximum). Talking in general about lua, not knowing what lpdf.checkedkey is, does and is supposed to do, does not look like efficient use of time.

you can try this (untested) function lpdf.checkedkey(t,key,variant) local pn = t and t[key] if pn then local tn = type(pn) if tn == variant then if variant == "string" then return pn ~= "" and pn or nil elseif variant == "table" then return next(pn) and pn or nil else return pn end elseif tn == "string" then if variant == "number" then return tonumber(pn) elseif variant == "boolean" then return toboolean(pn) end end end end ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

On 9/15/2014 8:25 PM, Michail Vidiassov wrote:

Dear Hans,

...

well, they're just not treated special

IMHO, they have to be treated special.

...

you can try this (untested)

I have tested it. It adds nice enhancement, but does not fix the bug In the following case local a = {} a["e"] = "blabla" a["t"] = "true" a["f"] = "false" a["x"] = true a["y"] = false a["z"] = nil

your new lpdf.checkedkey correctly fetches "t" and "f", where the old one failed. And your new lpdf.checkedkey fails for "e" - if I attempt to fetch it as boolean I get false instead of nil. (That is caused by toboolean returning false for unconvertible data - unlike tonumber).

But I did not complain about reading strings!

My problem was with "y". Both your new and old lpdf.checkedkey fetch it as nil instead of false. My (somewhat ugly) idea of the fix is the following

local function lpdf.checkedkey(t,key,variant) local pn = t and t[key] if pn then local tn = type(pn) if tn == variant then if variant == "string" then return pn ~= "" and pn or nil elseif variant == "table" then return next(pn) and pn or nil else return pn end elseif tn == "string" then if variant == "number" then return tonumber(pn) elseif variant == "boolean" then if pn == "true" then return true elseif pn == "false" then return false end end end elseif t and t[key] ~= nil and variant == "boolean" and type(t[key]) == "boolean" then return t[key] end end

more like function lpdf.checkedkey(t,key,variant) local pn = t and t[key] if pn ~= nil then local tn = type(pn) if tn == variant then if variant == "string" then return pn ~= "" and pn or nil elseif variant == "table" then return next(pn) and pn or nil else return pn end elseif tn == "string" then if variant == "number" then return tonumber(pn) -- or nil elseif variant == "boolean" then return string.is_boolean(pn,nil,true) end end end end ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------