lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

2012/2/17 steve donovan <>:
> On Fri, Feb 17, 2012 at 8:40 AM, Xavier Wang <> wrote:
>> first, may be we can split this module into some sub module. I mean,
>> ml.string/ml.table/ml.functional etc. it would be better.
> Ah, but I already have a library that works like that ;)  It's true
> that these are fellows that don't belong together, splitpath and
> compose, it's not elegant. But I'm trying to keep things as simple as
> possible.
penlight? but it's maybe too big for someone :-)
maybe split to modules is a bad idea with a compact small module. but
to  implement it in C in a single so/dll is very easy. I hope we can
have a module that can be compiled in a single ml.dll and have all
these function available. and can offer a ml.lua for other that don't
like binaries.

>> require 'ml.table'.export(_ENV)
> I do like this one, except maybe export() should put the functions
> into either __ENV or the local function environment (we are still in
> that awkward transition phase between 5.1 and 5.2 ;))

export function not only can export thing into _ENV, you can used like this:
require 'ml.table'.export(table)
and using ml functions in std table module.

I have a mistake :-(, require 'ml'.export(_ENV) will add functions
into table/string...etc. but require 'ml.table'.export(_ENV) will
export table functions into _ENV, that's bad, maybe export(table) will

>> Is that worth? we can discuss a function list in ml, and I have time
>> to implement then in C. some of things I though:
> That's an interesting possibility. I _suspect_ that most of them are
> not going to be much faster in C.[1]  (At least on the desktop, LuaJIT
> makes plain jane Lua code run very fast)

not only for fast, e.g. implement bind in C will very easy and needn't
any table allocation. ml.vararg is the same. and it can be compiled
into a big program -- just like game core. sometimes we need only
scripts for logical, and support library are all in one executable

>> is this list complete yet?
> It's very close to core Penlight function set.

I only thought penlight is somewhat too big for me :-(

I want a small but complete library.

> steve d.
> [1] Happy to be corrected on this, of course. But then the question
> becomes: how fast do they need to be?