lua-users home
lua-l archive

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


On 2015-07-08, at 4:43 AM, Dirk Laurie <dirk.laurie@gmail.com> 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.

Jay