lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Thursday, July 9, 2015, Jay Carlson <> wrote:
On 2015-07-08, at 4:43 AM, Dirk Laurie <> wrote:
> The main reason why aggregate constants would be nice to have in
> Lua is that more lurking bugs can be caught at compile time.

If not at compile-time, then lexically closer to the cause of error. My mantra is prompt local diagnosis. Anyway, the original question was API design:

In languages without automatic storage management, it is very important for APIs to document who is responsible for allocating and deallocating structures. Libraries become easier to create and use if you don't have to track who owns storage.

In some languages with ASM, the String datatype is mutable. I think of Smalltalk-80 as the exemplar. Most modern languages have immutable Strings. This also simplifies API design: it does not need to be documented who "owns" a String, and who is allowed to modify it. With mutable Strings, libraries and clients tend to make "safety" copies of Strings to make sure they don't get mutated out from under them.

"Tuples" provide a similar function to modern Strings: an anonymous, immutable datatype. Nobody has to document who is allowed to later update a tuple, and nobody needs to shallow- or deep-copy them to guard against accidental reuse.

A separate "tuples" idea makes the most sense in Lisp-like languages. In Java, classes of Plain Old Java Objects (POJO) marked final serve much the same purpose. Pure functional languages have no need, since all lists are immutable.

MOO (and other MUD languages) have no mutable lists because MOO is all about supporting mutually-suspicious programmers in the same image, and many mutable-list bugs would be security-sensitive.


In the examples that I've come across, most have to do with emulating multiple return values, or the avoidance of temporary / garbage objects, when multiple return values are required. So, this motivation is not really present in Lua. 

Also, tuples in other languages appear to be restricted in other ways, too (the count, the allowed types). But that seems like a nod to the compiler/efficiency and to the common use cases where they are employed. 

A couple of years ago I had asked Roberto about constants. He suggested that I was asking for a newindex metamethod that was triggered on every update, not just for absent key/values. Perhaps this is a small hint about the light in which these ideas are viewed and which approaches are likely to gain traction. Maybe most of these suggestions are just extending table symantics...

For my education on tuples, I'd be helped if someone could provide a real world application that would be done more simply with tuples and would be difficult, otherwise. As is, they seem like a way to deal with a lack of multiple return values... Or multiple return values seem like a good-enough way to do many of the things that tuples do.