Re: microlight review

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

On Sat, Apr 28, 2012 at 10:45 PM, David Manura <dm.lua@math2.org> wrote:
> to use Microlight rather than roll their own functions.  As a case in
> point: ml.escape is currently incompatible with 5.1 due to \0
> handling.  Test case to add:

Not sure how to fix this, because the Lua 5.1 handling of \0 is not consistent:

> =('a\000'):find'\000'
2       2
> =#('a\000'):match'\000'
0

i.e. works fine for _finding_, but you get an 'empty' string when matching.

> On my suggestion about merging ml.extend and ml.inject (and perhaps
> even ml.delete, like splice), I see there was already some discussion

The latest push does some renaming: 'inject' has become insertvalues
and 'delete' has become removerange.

count_keys becomes simply count, and has_keys becomes issubset.

> Speaking of conflating, ml.import is described as both a primitive
> table operation (which perhaps should separately be ml.update) as well
> as something more involved

I'm increasingly convinced that ml.update and ml.import are different
functions (in fact, is import actually used?) As a temporary stand-by,
update is a synonym for import.

> .  ml.ifind and ml.indexof are
> related, differing in that one accepts a `pred` while the other
> accepts a `value`, but they also differ in that one returns a key and
> other returns a value.

I've taken the liberty of giving indexof an optional extra argument
which is the function to test for equality. Given that, my feeling is
that ifind should be deprecated.

> We may still want a shallow table copy operation that handles non-sequences.

ml.update({},t) does that job currently.

> The docs could mention that ml.collect works only on stateful
> iterators and collects the first value.  ml.collect(pairs{1,2,3})
> would fail.

I was bothered by this, especially when remembering that LuaJIT
implements io.lines() as a stateless iterator (it returns a function
and the file object). So now ml.collect() works with io.lines and
pairs/ipairs.  In the process, it had to lose some optional (and
somewhat confusing) arguments.  (For the pairs/ipairs pattern of
key/value iteration, it collects the value, otherwise the first loop
variable)

There is now a collect_until(pred,iter) which also works with all
iterators, with pred either being a number or a predicate. I'm not
entirely convinced it's a good idea to override the argument like
this, and perhaps collect_n should be a separate function.  The
'thirty function' limit is arbitrary, of course.

> These things were probably discussed at length before, but my
> experience is to often want a dumper for debugging and occasionally
> for basic serialization.

That's my experience as well. To go beyond that, one needs a
configurable serializer and I think there are some more industrial
modules out there for this specific purpose.

I've put in memoize, which was part of Jay's original proposal.  I'm
itching a little to add writefile as well as readfile, and there has
been a request for a good trim function.

A design decision that needs review is that all functions returning
arrays label them explicitly as Array objects.  It is trivial to give
them a new identity but I'm wondering if this is a wise move for
generic functions.

Again, thanks for this detailed review; it's really what every module
writer needs, and is lucky to get.

steve d.