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"

  local tinsert = table.insert

* 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 }

* as far as ipairs is concerned, a nil value signifies the end of a table, so if you have:

  { 1, 2, nil, 3, 4 }

* 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

* 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()

  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

  function seq( ... )
      local that = nil
  
      for i = 1, select( '#', ... ) do
          local fn = select( i, ... )
  
          that = with( { ["that"] = that }, fn )()
      end
  
      return that
  end

  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 )

  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

http://www.lua.org/manual/5.1/manual.html

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 }

  local blah = { bleh = "yep", bleagh = "whatever" }

  -- both of the following are valid
  print( blah["bleh"] )
  print( blah.bleh )

  local blah = { "my", "name", "is", [12] = "slim", [888] = "shady" }

  local blah = { "element 1", "element 2", name = "son", lastname = "goku" }

  local blah = { { "star", "bucks" }, { "apple", "sauce" } }

  local blah = { [{ 1, 3, 5 }] = "odd", [{ 2, 4 }] = "even" }

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 )

  print( 8 * i^5 + 2 * i )

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

here's a description of metatables:

http://www.lua.org/manual/5.1/manual.html#2.8

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

  (def observe (row col range)
      (accum append
        (for i (- range) range
        (for j (- range) range
            (aif (showpos (+ row j) (+ col i))
                 (append it))))))

  (def showpos (row col)
      (aand (world row) (it col)))

-.variable = (* -1 variable) work just fine in arc.

  arc> (to-nearest 5.123 .1)
  5.1000000000000005

  (let (f1 f2) nil
    (def f1 () (prn "bob") (f2))
    (def f2 () (prn "bib") (f1))
  
    (f1))

  (withs (f2 nil
          f1 (fn () (prn "bob") (f2)))

         (def f2 () (prn "bib") (f1)) ; f2 can't be bound again in the withs part, maybe a bug
  
      (f1))

  (mac mrec (fns . body)
   `(let (,@(map1 car fns)) nil
      ,@(map1 (fn (f) `(def ,@f))
              fns)
      ,@body))

  arc> (mrec ((f1 () (prn "bob") (f2))
              (f2 () (prn "bib") (f1)))
         (f1))
  bob
  bib
  bob
  bib
  ...

Destructuring in lets is a nice idea, and using this with nil is a cool hack, but until and unless this behavior is changed, don't rely on it in macros - it can cause unexpected code breakage. A better way to do it would be the following (my 'fwithr is your 'mrec).

    (mac withr (bindings . body)
      (let bindings (pair bindings)
        `(with ,(mappend [list car._ nil] bindings)
           ,@(mapeach b bindings
               `(set ,@b))
           ,@body)))

    (mac fwithr (fns . body)
      `(withr
         ,(mappend [list car._ `(fn ,@cdr._)] fns)
         ,@body))

http://news.ycombinator.com/item?id=265111

  (def avg2 (lst)
      (avg (flat lst)))

  '(1 2 3 (3 4 5) (3 4 (1 2 3)))

  (/ (+ 1
        2
        3
        (/ (+ 3 4 5) 3)
        (/ (+ 3 4 (/ (+ 1 2 3) 3)) 3))
     5) ;= 13/5

  (/ (+ 1 2 3 3 4 5 3 4 1 2 3) 11) ;= 31/11

  (def wrand args
      (withs (weights (sort (compare > car) (pair args))
              unit   (/ 1.0 (reduce + (map car weights))))
          
         (ccc (fn (return)
             (with (acc 0 r (rand))
  
                 (each (weight val) weights
                     (= acc (+ acc weight))
                     (if (< r (* acc unit))
                         (return val))))))))

  (defun wrandf (xs weights)
    (loop with r = (random (apply #'+ weights))
          for x in xs
          for w in weights
          for cw = w then (+ cw w)
          when (> cw r) return x))

  ; assumes pair
  (defmacro wrand (&rest args)
    `(funcall
       (wrandf
         (list ,@(mapcar (lambda (x) `(lambda () ,(cadr x))) (pair args)))
         (list ,@(mapcar #'car (pair args))))))

  (d!car '(1 2 3))

  (def d (op)
      (eval op))

i don't know what the OP is asking exactly, but the answer is likely yes. i implemented coroutines, so these more straightforward things should be no problem

i talk about it a bit on the blog post, but the problem with continuations is the freaken name. it sounds like some sophisticated thing, when in fact all it is is marking the next instruction. for example:

  (ccc func)

  (ccc [do (stuff...)
        (if blah (_ bleh)) ; early return
        (do more stuff)])

and because it's the next spot, and because you can call _ as a function, they refer to it with the holistic name "continuation," instead of "the spot after the ccc"

they could have just as easily made the primitive be mark-the-current-spot, a la:

  (ccc [= spot _])