Re: [ANN] Lua 5.2.1 (work1) now available

[Hisham <h@...>]

On Wed, Mar 21, 2012 at 7:03 PM, Roberto Ierusalimschy
<roberto@inf.puc-rio.br> wrote:
>
> > I imagine that one problem is going to be programs that use
> > memoization, in which case the keys are often pretty arbitrary
> > (whereas "typical" use of string keys probably favors short strings)
> > _and_ expected to be fast.  this seems to be a pretty popular
> > technique in Lua...
>
> Unlike short strings, long strings rarely are literals in the program.
> People tend not to write t.thisIsAVeryLongStringButBarelyLongEnough.

As a curiosity, I ran a script through my sources at work to find how
long were the longest strings in actual use as table keys (module
function names, etc) in production. In one project, four keys are 32
characters long, 16 keys are longer than that (the longest key is 47
characters long). In another, the longest key is 42 characters long,
the second longest is 28 characters long. We're running 32-bit
binaries, BTW.

In the LuaRocks sources, the longest key is
"split_source_and_binary_results", which is 31 characters long.

Here's the script if anyone wants to play. This was a quick-n-dirty
command line job, actually: it doesn't ignore string literals, but
it's easy to eyeball which words are parts of strings and which ones
are actual table keys/function names.

find . -name '*.lua' -exec cat '{}' ';' | lua -e 't={}; for line in
io.lines() do for word in line:gmatch("[A-Za-z0-9_]+") do t[#t+1]=word
end end;  table.sort(t, function(a,b) return #a == #b and a < b or #a
< #b  end); for _,line in ipairs(t) do if line~=last then print(line)
end last=line end'

-- Hisham
http://hisham.hm/