Re: microlight review

[David Manura <dm.lua@...>]

Proper 5.1/5.2 compatibility may be another reason people would want
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:

  local ml = require 'ml'
  local charmap = string.char(unpack(ml.range(0,255)))
  assert(("aa"..charmap.."bb"):match(ml.escape(charmap)) == charmap)

On my suggestion about merging ml.extend and ml.inject (and perhaps
even ml.delete, like splice), I see there was already some discussion
("Is there really an benefit for conflating insert() and append()"
[1]), though there was also a goal of keeping the number of functions
under 30 (e.g. no "prepend()").

On Sat, Apr 28, 2012 at 4:04 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> somehow I got persuaded to use ml.import. (Both names make
> sense, in context, and here an alias will do fine.)

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 dealing with packages/require, including
the deprecated getfenv (that users may prefer to avoid even in 5.1),
plus _ENV == _G here.

Common usage in existing programs rather than invention should dictate
in design choices, but I'm not sure about the
ifind/indexof/imap*/ifilter functions.  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.  Finding whether an element exists in a
collection like an array (or, more completely, it's index to operate
on it) is common, so I do at least want ml.indexof.  With
imap*/ifilter, there's some design questions (e.g. in-place operations
v.s. returning copies), though the copying approach chosen is probably
the safer option in the common case.  We may still want a shallow
table copy operation that handles non-sequences.

> function ml.callable (obj)
>     return type(obj) == 'function' or getmetatable(obj) and
>       getmetatable(obj).__call
> end

It could be noted that this may fail if __metatable is set, at least
without a __metatable.__call.  BTW, the special case of mt.__index ==
mt (as imposed by ml.class) implies `obj.__call` can also be tested
(and likewise for other operators).

I suppose it should also be noted that ml array operations are not
raw, like `table.*` functions are.

Maybe ml.count_keys should be ml.kcount or just ml.count, analogous to
naming conventions like in ml.imap and `ipairs/pairs`.  Like Dirk
mentioned, "subset/countset/equalset" are more obvious to me than
"*_keys" since these will *usually* be used for sets.  It may be
mentioned in the tutorial that `if next(t)` or `if next(t) ~= nil` has
been one idiom to test for empty set.  Another idiom: `not not o ==
ml.truth(o)`.

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.

TODO: Add precise semantics/tests of ml.split.  ml.split(s, '') can be
ambiguous but presently has the Python, not Perl, behavior.  The
obscure case ml.split("asdfsadf", '.-') hangs, unlike Python.

> An interesting question I've been discussing with Vadim; tstring
> should be as correct as possible, as long as it remains a simple
> robust debugging/light serialization tool.

These things were probably discussed at length before, but my
experience is to often want a dumper for debugging and occasionally
for basic serialization.  Rarely are cycles needed for basic
serialization (e.g. they are not in json or XML), but I may want them
for debugging since they can occur in memory (intentionally or
accidentally).  Therefore, if we're talking about covering 95% of use
cases, I think Perl's Data::Dumper default is reasonable:

perl -E 'use Data::Dumper; $t = []; $t->[0]=[$t], $t->[1]=$t->[0];
print Dumper($t)'

        $VAR1 = [
          [
            $VAR1
          ],
          $VAR1->[0]
        ];

  Quote: "The default output of self-referential structures can be
evaled, but the nested references to $VARn will be undefined, since a
recursive structure cannot be constructed using one Perl statement.
You should set the Purity flag to 1 to get additional statements that
will correctly fill in these references." -- [2]

[1] http://lua-users.org/lists/lua-l/2012-02/msg00731.html
[2] http://search.cpan.org/perldoc?Data%3A%3ADumper