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

[Dirk Laurie <dirk.laurie@...>]

Op 18 februari 2012 19:54 schreef steve donovan <steve.j.donovan@gmail.com> het volgende:

Since people have said such nice things to me I've made a new version,
at a more convenient home:

https://github.com/stevedonovan/Microlight

…

The readme.md is fairly extensive, and hopefully covers most of the ground.

And from readme.md, I latch on to:

> It's the start of a community process to find the Top Thirty useful functions.

1. Every user of Microlight will say every time
   
        tostring = tstring

(in the process destroying the original `tostring`). Rather put

        ml._tostring, ml.tostring = tostring, ml.tstring

in the module.  Then ml.tostring gets imported with the others, and
those that want the old one back can always say `tostring=_tostring`,
with `tostring=tstring` still available if needed.

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.

3. I more or less like these functions as-is:
bind1 bind2 callable class compose exists expand extend
ifilter ifind imap imap2 import indexby indexof
keys readfile split splitext splitpath sub tstring

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")

5. But actually I'm not fond of the approach in which it is tacitly assumed that
table arguments are lists or sets.  The standard table library has confused enough
people over the years.

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.

List(L): equip table "L" with the List metatable and return L
Set(S): equip table "S" with the Set metatable and return S

The List metatable would contain the standard table library and some ml
functions, plus 'sorted' (so that L:sorted() not only sorts L, but also returns it).

Personally I have no objection to metamethods in these: L1..L2 for extend, S1*S2 for
intersection, S1+S2 for union, etc.

6. function_arg is not a top-30 candidate.  It can stay local to the module.
Another function that does not add enough value to justify a name is tdump.

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

8. I don't see myself using binop.

9. mlx is a toy for people who like functional programming.  I'm grateful you
did not include any of that in ml.  Using the debug library to set a metatable
for functions is as you say: evil.  Please change the name of mlx to something
that does not suggest a close association with ml.

Dirk