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

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

On Sun, Feb 19, 2012 at 8:30 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> Op 18 februari 2012 19:54 schreef steve donovan <steve.j.donovan@gmail.com>
> het volgende:
> 1. Every user of Microlight will say every time
>         tostring = tstring>
> (in the process destroying the original `tostring`).

This is a hack intended to make life easier for interactive users.  I
should insert a stern warning ;)

tstring is intended as a debugging convenience, not for serialization.
It could acquire some flags that sacrifice prettiness for correct
serialized form.

> 2. I'm missing a "help" function.  Without argument, it would return
> keys(ml),
> with argument, a little information about the function, enough to remind
> one how to use it.

I tend to say 'ldoc -m ml' which does the same thing on the command
line.  But for interactive use, help() would be useful, especially if
there was a docstring convention.

> 4. I don't like these names:
> makemap (rather "invert", since invert(invert(t)) will usually be a replica of t)
> subset (rather "contains_keys", with arguments swapped)
> tequal (rather "keys_equal")

invert() reads nicely.  And tequal() is definitely a wrong name given
its definition using contains_keys().

> I prefer an object-oriented approach in which sets and lists are predefined classes.
> We've got it in the core for strings, we don't have it for tables because
> tables are  too versatile to tie down.  No such objection for lists and sets.

It is very convenient to have these classes available. Actually mlx
has a List class which wraps table.* and the list-like ml functions.
(And I'm still having cognitive dissonance from List vs Array)
List.sorted() is a good idea, or wrap List.sort() so it returns its
argument.

> Personally I have no objection to metamethods in these: L1..L2 for extend,

Yes, I'm missing concatenation in List. It has a simple definition
using extend, but returns a new list.

> S1*S2 for intersection, S1+S2 for union, etc.

I'm tempted...

> 6. function_arg is not a top-30 candidate.  It can stay local to the module.

It's deliberately not documented since it gets used as a back-door for
redefining what ml thinks of as a function.

> Another function that does not add enough value to justify a name is tdump.

I've come to agree with this  - print(tstring(t)) does the job well enough.

> 7. The numerical option in foreach is confusing, and the example of its
> use in readme.md is bizarre.

Perhaps a straightforward foreach is useful. table.foreachi passes
both the index and the value, and it's deprecated anyway.

The example was motivated by a gap in ml: there are bulk operations
for setting and getting multiple keys but nothing for removing
multiple keys.

(There is a temptation to game the system and overload functions too
much.  table.insert is already a standard function which is really two
functions, insert() and append())

> 8. I don't see myself using binop.

It made sense at the time. Say I have

> records = {{name='alice',age=23},{name='bob',age=21}}
> table.sort(records,binop('age','<'))

But probably not a top 30...

> for functions is as you say: evil.  Please change the name of mlx to
> something  that does not suggest a close association with ml.

That's easy enough.  What about moving mlx's List into ml, plus a Set class?

steve d.