Re: Standard Libraries:

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

On Mon, Dec 21, 2009 at 9:17 PM, Mark Hamburg <mark@grubmah.com> wrote:
>> The interesting operation is the :upper() call, which is equivalent to
>> :map(string.upper). The idea is this: if a method is not found in the
>> Seq type, then assume that it is a method of the element type.
> It does push for making the sequence methods less likely to overlap on namespace. Michael Franz's work in Lagoona on namespaces for messages was interesting in that regard.

Interesting idea, that messages (methods) belong to a module...

Some overlapping seems inevitable, in the case of the type having a
method also shared by the component, in which case an explicit
map-by-name is always possible.

The sequence container can contain extra namespace information.
Consider the problem of filtering a sequence of files and doing
something path-related with the result:

-- an iterator over all the process command-lines in Linux (e.g
/proc/2343/cmdline etc)
seq(lfs.dir '/proc',path):match '^%s+$':join 'cmdline'

Here I'm assuming that join() is inside the table path, so the
iterator container contains extra information to resolve any methods
on the values; this is then a typed sequence without actually needing
typed objects.  Note also that the implicit map of match() over the
strings acts like a filter, since we must not let any nil values
propagate through the iterator (see a parallel discussion about map()
and tables-with-holes)

The traditional Lua approach (add a metatable to the objects) of
course doesn't work here, since strings share a metatable and are not
virtualizable [1]

There is a potential problem when some method on the chain actually
changes the value type, e.g. if we were to use map(tonumber) instead
of match.  (It would actually be useful if tonumber was also in the
string table)

steve d.

[1] http://lua-users.org/wiki/LuaVirtualization.
Would be interesting to know the actual cost of allowing strings to
have individual metatables.