Re: Microlight

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

2012/12/18 steve donovan <steve.j.donovan@gmail.com>:
> On Mon, Dec 17, 2012 at 11:05 PM, Vadim Peretokin <vperetokin@gmail.com> wrote:
>> I don't quite agree with the 'use Arrays if you want to use MLs table
>> functions' idea, sorry. Why force the user to do that? I'm actually quite
>> fond of some of the table functions, and don't use ML Arrays personally at
>> all.
>
> I think I'm with Vadim on this one; not all tables are Arrays, and the
> 'number of slots' is not a hard-and-fast criterion. After all, there's
> very little code duplication since Array mostly wraps the table
> functions. The issues Dirk mentions seem manageable with sufficient
> documentation, e.g free-standing imap but Array.map, etc.
>
> Of course, Array.map can be used with any suitable table as an
> argument, but has to return an Array, unless we implement covariance
> (that is, type A -> map -> type A)

I forked the thread because Microlight is too specialized for the
original topic, but it's still to my mind a question of API design.
I like API's that do the one thing I need simply but well. It sets my
teeth on edge that some Microlight routines accept ordinary
tables and return Arrays.

It is still useful to me even though I no longer require the module.
I copy-and-paste the two or three routines needed for that particular
application and get some coding ideas even from the ones I don't use.
It's like one of those sampler CD's that Naxos occasionally brings out:
most of the stuff is not quite yiour kind of music, but one or two tracks
make you want to go and buy the full album from it came.

Microlight is also rather like a 30-piece tool set of the kind that people
like to give as Christmas gifts: a few drill bits for wood, some for
metal, some for brick, some screwdriver bits, a few hex sockets.
You can't expect it to satisfy everybody. The woodworker does not
need the sockets but would dearly have loved a countersink bit, etc.

Let's agree to differ on this one. I say you can opt for either an
approach that uses no metatables, implying no Arrays (this would
please Vadim), or bring in Arrays everywhere (this would please
me). You say you can continue trying to do both at the same time.
Good luck to you.

Dirk