Re: microlight review

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

On Wed, May 2, 2012 at 12:17 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> Easy enough to say e.g.
>    local inject = ml.insertvalues
> In such cases Microlight should prefer long but descriptive
> to snappy but cryptic function names.

That's the idea - let the user get as cryptic as they like, but this
is not Fortran or Unix on a teleprinter.

>    require"ml".import()

I think it's fine for that role, it's just one of those functions that
does two somewhat different things as David observes. update and
import should be separate functions for that reason (I have a tendency
to pack too much in a single function)

> Conflation is much more acceptable with table argument lists. E.g.
>   import{journal,into=ledger}
>   update{ledger,from=journal}

I do worry about the need for an extra table creation here, since esp.
update needs to be practically a primitive.

> There has also been a suggestion, complete with proof-of-concept
> implementation, for a wrap function.

How do others feel about this? And Bertrand's suggested trim() function?

> On another issue:  One of the reasons why Python can get away with
> a maze of twisty little passages, all alike, is the self-documenting
> system.

Sure, a doc-string convention isn't difficult, maybe I'm being
over-anxious about adding documentation as live strings, just for the
occaisional interactive convenience; perhaps there should be an
ml_help separate module[1]  (I agree that a big beast like ldoc is
overkill for the job [2])   It's definitely a thing that I appreciated
when learning Python.

steve d.

[1] a clever Lua REPL could load such doc modules automatically, if a
convention was followed.
[2] but one of its output formats could be such a 'doc module'