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

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

On Tue, Feb 21, 2012 at 2:46 AM, Jay Carlson <nop@nop.com> wrote:
> path with LOM (well, it was lxptree at the time). Because I was going
> to be working with code I didn't control, I realized all of my public
> functions would have to rewrap their arguments, and in that particular
> case, deep-rewrap them. And hope nobody else had their own enhanced
> list-like things.

Very true, which is why I respectfully disagree with Dirk that all ml
list-like functions should live in a List class. The original
functions must all be available to fit with other coding styles and
code bases.

> Speaking of guilt-by-naming, I was wondering if the class stuff ought
> to have explicitly-ml naming, like mlclass().

Here I'm with Dirk: ml.class is distinct enough.

> OK, of all of them I suppose that's the least objectionable. If you
> ever use it in a loop you'll be really sorry though, since it can't
> really mutate L1, right?

That's true. It's a nice notation, but not a very efficient one.

BTW, #s is (a) unavoidably O(N) [1] and (b) only works for 5.2.  So
perhaps we need count_keys() as well.

steve d.

[1] OK, we can imagine an implementation that tracks the size, but
then sets are no longer simple tables. It's best to keep the
bog-simple implementation and warn people about cardinality
operations.