Re: Tuples and other constant values

[Tim Hill <drtimhill@...>]

> On Jul 7, 2015, at 5:50 PM, Daurnimator <quae@daurnimator.com> wrote:
> 
> On 8 July 2015 at 10:34, Tim Hill <drtimhill@gmail.com> wrote:
> 
> I don't think that's a good assumption.
> In the case of memoisation: just as often I want to memoise based on
> if I was given the same table, as if I was given the same table
> contents.
> If a programmer needs to memoise based on table contents, it should be
> up to them to serialise it.

The choice of content vs identity in equality testing is domain specific. I am unclear, however, of the utility of memoziation based on table identity only, and in any case identity is already handled within Lua and so is not at issue here. Serializing is not particularly efficient (or easy) in Lua, hence much of this thread.

> 
> I'm saying a tuple should be an immutable collection of it's arguments.
> This means that a given tuple always has the same contents.
> However, the contents can change.
> These tests should pass:
> 
> local s, t = {}, {}
> assert(tuple("foo", s) == tuple("foo", s))
> assert(tuple("foo", s) ~= tuple("bar", s))
> assert(tuple("foo", s) ~= tuple("foo", t))
> local tmp = tuple("foo", s)
> s[1] = "testing"
> assert(tuple("foo", s) == tmp)
> 


But this is just equivalent to a regular table that has a metatable to over-ride equality (to do a shallow compare), and make the table immutable. The purpose of the OP was to allow multi-key tables, and to introduce a “tuple” to act as the stand-in for multi-keys. Such a use-case uses value semantics, and therefore requires that the values are “deep” immutable. This is essentially similar to Python, where dictionaries are keyed on values not identity, and therefore can have (immutable) tuples as keys, but not other dictionaries.

—Tim