gistfile1.rb

# Conditional decrement.
#
# Decrement the value of a key only if the current value is greater than
# a specified value.

require 'rubygems'
require 'redis'

r = Redis.new
cond_decr = <<LUA
    local value = tonumber(redis('get',KEYS[1]))
    if value == nil then return {err="Value at key is not integer"} end
    if value > tonumber(ARGV[1])
    then
        value = value - 1
        redis('set',KEYS[1],value)
    end
    return value
LUA

r.set(:x,4)
5.times {
    puts(r.eval(cond_decr,1,:x,0))
}

Right, I missed that.
Error handling with assert()/error() would be better here, since return nil, "string" is better to be reserved for returning multiple redis values (there is a NIL value in Redis afair).

Any reason why I shouldn't eval a library of functions like https://gist.github.com/951084 and use function calls instead of pass a block of code with every eval? Is the lua context likely to be flushed in some future revision?

BTW global by default will be a pain unless you use local.

@agladysh: I thought that Redis multi-bulk replies were handled by a table. The way I thought the mapping would happen is:

• Integer replies translate to number.
• Bulk replies translate to string.
• Status replies translate to...maybe also string? That may get confusing, but on the other hand you rarely have commands that can return bulks or strings.
• Multi-bulk replies translate to table.
• Nil multi-bulk replies translate to nil.
• Error replies either return (nil, "error") or raise a Lua error. This one may take some experimenting to figure out which works better.

@shirro: The Lua state would probably not be flushed, but it is possible that more advanced sandboxing techniques would prevent that from working. If you wanted to do something like that, you could use string.dump to dump the function to bytecode, store it in a key, and then EVAL something like local f = loadstring(redis.get("myscript.lua")); f()

Hey, thanks for the suggestions. @leafstorm: the translation happens exactly as you described it but for errors.
My point for using {err = ...} is that I want all the errors be single return values for a matter of unification, since in lua you can do something like:

return redis("get",...)

And everything happens in the real command is returned by Redis, BUT for status code reply, for which I should probably use {ok=...}.
Similarly you should be able to call a Redis command without even caring about what he returned, save the reply into a var, and return it later as the user directly called Redis:

reply = redis(".....");
... do more stuff ....
return reply

I think this is much more important compared to Lua idiomatic error handling since what hides inside the above concept is that Redis errors are a data type and not a condition.

Btw nothing is written in the stone as this is an "idea evaluation" branch and we can change everything in the future.

Why don't you declare global functions "set" and "get" instead of putting everything in a "redis" function? It would improve error message consistency: you wouldn't have to create a special error message to tell the user the command is unknown, he would get an "attempt to call nil" kind of error.

@antirez: Yeah, but:

1. That means that errors don't evaluate to false in an if statement.
2. It's very unlike normal Lua behavior, which would probably confuse people who already know Lua.

I still think that representing Redis errors with Lua errors would be the best solution. 90% of the time, errors in Redis represent exceptional conditions like improperly calling a command, which is exactly what Lua errors are used for. If there was a time where not directly erroring to the user was important, you could local ok, result = pcall(redis, "get", somekey). ok would contain true or false depending on whether it worked or not, and result would contain either the result of the operation or the error message.

The {ok = "OK"} is a pretty good idea though.

@doub: Because then he would have to define a C-level function for every single Redis command, not to mention polluting the global namespace to heck.

@leafstorm: If you have a single function, you have to do the dispatch inside the called C function anyway. If there are that many commands to bind, use a code generator. And to avoid polluting global namespace you can put it in a (preloaded) module.

@doub People could do something like https://gist.github.com/952677 if they need it. It might be better to leave such things to third party lua libs and keep the redis code simple.