Re: [ANN] Microlight (was Re: paving cowpaths with libraries)

[steve donovan <steve.j.donovan@...>]

On Mon, Feb 20, 2012 at 11:36 AM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> Op 20 februari 2012 08:56 schreef steve donovan <steve.j.donovan@gmail.com>  het volgende:
> 2. Noted with interest that Penlight is installed as a dependency
> (Microlight   users almost by definition wouldn't want that)

Noted. For ldoc I finally broke down and tried to reuse a library ;)

> 4. Made an executable calling it (on a Linux machine, that means changing
> its mode, inserting a first line that says it should be run as a Lua script,
> and linking it symbolically to ~/bin/ldoc.  On a Windows machine, I presume
> it means making LDOC.BAT.)

Yes, this is a luarocks issue - I had an ldoc directory and a script
ldoc.lua; LR makes an execute ldoc.lua available; the alternative
causes a namespace collision between ldoc the directory and ldoc the
script. Latest LR version will deploy ldoc.lua as a command ldoc, but
it's a bit of a mess.

> 5. Ran 'ldoc -m ml' and got a message about an invalid escape sequence.
> 6. Remembered why that happens and changed the first line to say it's a Lua5.1 script.

Should be easy to fix that, thanks. LR delivers 5.1 scripts, but
assumes that 'lua' means 'lua51'.

> ml.lua:217: ml.tdump: param and formal argument name mismatch: '...' 'f'
> ml.lua:383: ml.import: param and formal argument name mismatch: '...' 'other'

These errors will be removed, since it's common enough to use '...' to
properly discriminate between functions that take variable numbers of
arguments (plain nil check leads to bizarro errors)

> A note on "mldoc": it adds "help" and "wrap" to ml.

wrap() is a good candidate.

Apologies for bringing in the ldoc red herring, since the intention
was not to make it mandatory. A simpler and more specialized utility
that only uses ml would be very possible.  I like an interactive
help() (there's a project out there that does that, I dimly recall)

I like your Set with intersection and union operators; any Set class
that has regular methods no longer functions as a completely reliable
set, because you get false positives on method names.  It's a
limitation that we cannot distinguish between 'method' and 'field'
lookup, without using proxies that obscure the simplicity of
tables-as-sets.

To avoid confusion, I will move the experiments (mlx) to their own
repo.  I'm still sentimentally attached to '+' being a shortcut for
function(x,y) return x+y end etc, but tried to make it optional, hence
the ml.function_arg hack.

Should ml contain the List and Set classes?

steve d.