Live data from Hacker News

Lua Fun: A high-performance functional programming library designed for LuaJIT

github.com

31–34 of 34 posts

Re: Lua Fun: A high-performance functional programming library designed for LuaJIT

#31
post #30
post #4

> Reference Lua may not work and is not supported Any particular reason for that?

The initial idea was to make a functional library that works best with tracing JIT compiler. Functional paradigm on tracing JIT is the core innovation in the project. Lua 5.1 can run fun.lua after minor changes (I'll make patch soon), but I am not sure that performance will be good enough.

Do you think the performance is really going to be that bad in the regular Lua interpreter? I wonder if its going to be better or worse than the underscore.lua approach of using arrays instead of iterators.

Also, are you using lots of 5.1 specific stuff (setfenv, ...) or would this also be easily ported to 5.2?

Re: Lua Fun: A high-performance functional programming library designed for LuaJIT

#32

Is this similar to the functools package in Python? If so, that would certainly convince me to use Lua for some of what I use Python for.

Yeah, the library has some common functions with "itertools" Python's module [1]. fun.range syntax was even copied from Python's range. What is more, you can also take a look on Haskell's Data.List [2] or StandardML's List [3] packages.

[1] http://docs.python.org/2/library/itertools.html [2] http://hackage.haskell.org/package/base-4.6.0.1/docs/Data-Li... [3] http://www.standardml.org/Basis/list.html

Re: Lua Fun: A high-performance functional programming library designed for LuaJIT

#33
post #31
post #30

Earlier quoted context omitted.

The initial idea was to make a functional library that works best with tracing JIT compiler. Functional paradigm on tracing JIT is the core innovation in the project. Lua 5.1 can run fun.lua after minor changes (I'll make patch soon), but I am not sure that performance will be good enough.

Do you think the performance is really going to be that bad in the regular Lua interpreter? I wonder if its going to be better or worse than the underscore.lua approach of using arrays instead of iterators. Also, are you using lots of 5.1 specific stuff (setfenv, ...) or would this also be easily ported to 5.2?

The library code is Lua 5.1 compatible (except bitwise functions in "operator" submodule, but it can be easily replaced with "bit32" or even removed).

Some high-order functions heavily use recursion just to support multireturn iterators (yes, you can use multireturn with map, reduce, filter and so on). I plan to benchmark these parts and add optimized versions for non-JIT Lua if necessary.

I will try to make a patch in the next couple of days. Thanks for your interest!

Post reply on HN