i like how Lua is a language that "just works" (within reason of course.) i miss its awesometastic tables when using other languages. it's also rare in that it doesn't promote any particular paradigm. it lets you use what you feel is best. relatedly, its syntax is deceptively simple
anywho, i took a glance at the code. i know you're going for performance so maybe that affected the mechanisms you used, but here's some suggestions anyways:
* Lua's string concatenation operator is .., as in
return "str1" .. "str2"
* in tight code, local variables should be used anywhere possible. global variables require a table lookup, but local variables are on the stack (or register... one 'o thems.) so for example, you might want to have something like
local tinsert = table.insert
at the top or above the functions it's used in. it can't exactly JIT the table.insert because table lookup is dynamic (in both the tables you move around and the global environment)
* string.gsub might be faster than iterated replacement
* a key in a table can be anything, even functions and other tables, for the hex2int you can therefore have something like:
{ ["1"] = 1, ["2"] = 2, ... ["a"] = 10 }
i don't remember if the square brackets are necessary there
* as far as ipairs is concerned, a nil value signifies the end of a table, so if you have:
{ 1, 2, nil, 3, 4 }
ipairs will only iterate from 1 to 2. hence, depending on circumstances, you may be able to use this to make table splitting a bit faster
* table.concat might be useful somewheres
* a map-like function where on each iteration you return not just a value, but a key-value pair might be useful. eg pretending you don't care about performance, reverse could be written:
function reverse( a )
local len = #a
return tblmap( a, function( k, v )
return len-k+1, v
end )
end
it also makes mirroring tables easy. (again, ignoring performance. this is something you might use in the user code rather than in the library)
* one way i've set up bi-directional tables before is with __call. in that form, tbl[key] would access one way, and tbl(key) would access it in reverse. another option is something like tbl[1][key]/tbl[-1][key]. depending on how you're using the table, you can memoize in one of the directions and/or set up some sort of little database hidden behind that single table
* Lua doesn't have macros, but it does have first-class environments. among many other things this means it has anaphoric macro-like capabilities, except for the need to pass in expressions through closures or strings. take for example these lines from luarc.lua:
local sep = sep or ' '
local pattern = string.format ('[^%s]+', sep)
local f = string.gmatch (s, pattern)
local match = f()
using a function seq:
function seq( ... )
local that = nil
local original_env = getfenv( select( 1, ... ) )
for i = 1, select( '#', ... ) do
local fn = select( i, ... )
local new_env = { ["that"] = that }
-- have new environment inherit from old, otherwise
-- any global variables used in the fns will be unavailabe
setmetatable( new_env, { __index = original_env } )
setfenv( fn, new_env )
that = fn()
end
return that
end
or a shorter version if we have another function "with":
function seq( ... )
local that = nil
for i = 1, select( '#', ... ) do
local fn = select( i, ... )
that = with( { ["that"] = that }, fn )()
end
return that
end
we can write:
local match = seq(
function() return sep or " " end,
function() return string.format( "[^%s]+", that ) end,
function() return string.gmatch( s, that ) end,
function() return that() end )
this is an extremely questionable abstraction to say the least (note, none of this was tested,) but it's an example of some of the sorts of things you can do with first-class environments, which might help in betterizing the way the library is used. keep in mind that environments are tables, whose metatables may be set like any other tables, which need not be constrained to easy childish things like inheritance. eg:
do
local test_env = {}
local i = 0
setmetatable( test_env, { __index = function( tbl, var )
if var == "var" then
i = i + 1
return i
else
return _G[var]
end
end } )
setfenv( 0, test_env )
end
> print( var )
1
> print( var )
2
> print( var )
3
* finally, the horse's mouth is usually the best teacher:
Heh. Lua is pretty nice. Wrote a few mods for warcraft in it. The prefix notation is growing on me though as it appears to be clearer to my mind what is happening when things are written in prefix than infix (took a bit of getting used to though).
waow, thanks for the information (and for reviewing my code). I'm not a very proficient Lua developer yet, so I still have to learn a lot. Your advice will help...
> i miss its awesometastic tables when using other languages.
Would you mind expounding on how "awesometastic" they are? I gather that they have a nice implementation of vectors hidden under the table data structures (so conceptually a vector is just a table, but the runtime optimizes away vector-like usage into a true vector). Does it have more awesometastic properties?
i think it's the fact that those concerns don't occur in the language to begin with. from what i glanced (i can't find the pdf anymore,) the interpreter switches between different representations depending on how the particular table is used, and can switch between the representations dynamically for the given table (i'm not sure if the switching is bidirectional)
but the user never sees any of that. if you want an array or tuple you type
local blah = { 1, "two", function return 3 end }
if you want a hash table you type
local blah = { bleh = "yep", bleagh = "whatever" }
-- both of the following are valid
print( blah["bleh"] )
print( blah.bleh )
basically, any sequency, key-valuey, or structured ish thingie, i can just write out without worrying about anything. i'm sure it's doin' some sort 'o magic under the hood, but to that end they could be sacrificing lawn gnomes for all i care
and keep in mind that Lua is likely the fastest interpreted language... or at least it was before the Javascript optimization race started. i think one of the Javascript engines has features inspired by the Lua VM
and then there's metatables, which are properties that can be set to control the behavior of values in different situations. for example, one of the properties is __index, which is referred to when a table doesn't have a value for a given key. this enables straightforward memoization, inheritance, hidden data management, infinite data structures, etc
other metatable properties determine the operation of the value under addition, comparison, etc
you could, for example, implement complex numbers as if they were part of the language, simply by creating a seed table called i. when an expression such as 1 + 2 * i is reached, the __mul property would perform the complex multiplication, then return a new Complex table which would in turn perform the addition. along each step it would be a normal table, so you could do, for example:
print( (1 + 2 * i).polar_form )
keeping in mind that the table access is dynamic, hence polar_form can be calculated each time it's accessed, no need for getting/setting. also, this:
print( 8 * i^5 + 2 * i )
would work as it should because there's a __tostring property
i've been thinking of making an APL-like DSL (would be nice to be able to implicitly map and whatnot) in this sort of manner. i haven't looked deep into Ruby but i believe it has things of this nature
the fact that tables are used everywhere is unoverstatable. environments are tables, therefore you can do powerful things with environments. like writing your own import/include function, reading and writing global state in a file, anaphora and implicits... pretty much a bunch of crazy shit
along with this some very well-chosen features such as coroutines, closures, the implementation of most language features as modules (eg file.open, coroutine.wrap) to keep the syntax clean, etc
the tables by themselves go a long way, especially with their It Just Works® all-purpose syntax. but the way this flexibility is encouraged through the rest of the language makes it a wonderful unified package