Re: [ANN] Penlight Lua Libraries

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

On Sat, Apr 25, 2009 at 9:17 AM, David Manura <dm.lua@math2.org> wrote:
> Thank you.  The tutorial is especially useful.  I feel that a lot of
> modules don't well advertise themselves in terms of how the module is
> intended to be used in context with examples and design comments.
> Sometimes the docs are hidden in tarballs.

Documentation is key. It isn't the thing that gives us the greatest
pleasure, however!

> That's a bit ugly.  We're dealing with table arrays, lists, and
> sequences.  I feel there's a potential for confusion between these
> three.  The distinction between the three is not inherent to the
> problem domain (ordered sequences), yet the programmer has to decide
> which of these to use and how to fit them together.

OK, this is the real problem. Python makes the consequence of sequence
more explicit, whereas it isn't really a native Lua concept.  There is
for instance both seq.reduce and tablex.reduce, whereas a smart reduce
could work out from its arguments what operation was required. The
result in either case is a scalar. But the tablex/seq is mostly about
what the returned type is, so seq.map/tablex.map are returning rather
different things. An overloaded version would either return a sequence
or a table. If things were really consistent, it should not matter,
but this requires some very careful thinking.

> Perhaps some syntax support for list
> comprehensions could make it a bit cleaner.

They are a great notation, and I know there have been several proposals.

> I'm not certain I like your argument order for functions though.

Yes, I was being deliberately backwards.  But if we are _mostly_ using
prepackaged functions, then the argument is moot. The concern was that
when using the traditional order, the actual
table/sequence/list/whatever ends up at the end of a potentially long
anonymous function definition.

t1 = map(function(x)
	   return x*(x-1)
     end,t1)

We need to think these things out - the current API is not frozen at
this point! The idea remains to capture as many common patterns as
possible, and give them _clear names_. (that's not easy!)  Hopefully,
of the potentially thousands of patterns, we get a subset which
somehow spans the universe of patterns efficiently.

There's another danger, which I know from my C++ days. It is the curse
of the clever one-liner.  At university, we had some APL golfball
terminals, and the game was to print out a whole histogram with one
line of deliciously interesting symbols. Not a good way to write
actual _software_, IMHO.

steve d.