[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Microlight (was Re: paving cowpaths with libraries)
- From: steve donovan <steve.j.donovan@...>
- Date: Mon, 20 Feb 2012 12:02:34 +0200
On Mon, Feb 20, 2012 at 11:36 AM, Dirk Laurie <email@example.com> wrote:
> Op 20 februari 2012 08:56 schreef steve donovan <firstname.lastname@example.org> 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
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?