Re: [ANN] Penlight Libraries, First release

[David Manura <dm.lua@...>]

On Tue, May 12, 2009 at 2:46 AM, steve donovan wrote:
> On Tue, May 12, 2009 at 5:30 AM, David Manura wrote:
>> A main difference I see between tablex and List is that tablex
>> operations return a new list (immutable), whereas List operations
>> operate in-place (mutable).
>
> But it turns out (as Flemming Masden has suggested) to be very
> convenient for list operations to always return their self, to allow
> for method chaining (for instance, sort())

True.  table.insert and table.sort don't return the original table.
By extension, it would not make sense for tablex operations to return
the original table either.  However, I agree that there is
justification for List to support method chaining, which then indeed
implies that List ~= tablex.

It's still possible though for List operations to be convenience
wrappers around "lower-level" tablex operations if tablex operations
were (like table operations) made to operate in-place (mutable) as
suggested rather than being immutable as is currently.  The mutable
case is more fundamental than the immutable case given that an
immutable operation can be expressed in terms of a copy followed by
the mutable operation.

> The only gotcha would be
> that the expression 'l1 = l2:sort()' then creates the expectation that
> l1 and l2 are indeed different lists.

I doubt other designs would be less error prone.  The statement "l1 =
l2:sort()" would almost always be an error (e.g. a lint tool could
warn on it).  In the similar manner, the statement "l2:sort()" would
almost always be an error if the sort operation where instead made
immutable and returning a different list (like Perl's sort).  I have
at times made the the latter error in Perl.