Re: Weak tuples (was Re: upvalues and ...)

[Wim Couwenberg <debosberg@...>]

> The problem with this approach is that it makes all
> arguments and results
> persistent. Both weak arguments and weak results can
> be interesting in some
> cases.

Mark,

your example would not benefit from tuple entries
being weak.  (In the sense that an entry becomes nil
after gc.)  Here's how I interpret the issue.

1.  Entries in an immutable tuple are always strong.
2.  Special rules apply if a tuple appears as key
(value) in a weak-keyed (weak-valued) table.

Point 2 needs some explaining.  The important property
for weak tables is `reproducibility'.  For example,
numbers, strings and lightuserdata are never collected
from a weak table, even if the number/string/lud
appears nowhere else in the state.  This is because
values of these types can be *reproduced* exactly
(i.e. by equality) at any time.  This does not hold
for functions, tables and userdata, that are
reproducible only if a copy is still around.  In this
sense, a tuple is reproducible if and only if all its
entries are reproducible.  This implies how gc should
treat tuples in weak tables: they are removed as weak
key/value precisely when some entry is no longer
reproducible.  (I'm not sure how difficult this would
be to implement.)

There is another interesting approach: an immutable
tuple behaves exactly as is currently proposed for
`...'.  In particular you can not assign tuples to
each other:

    local a ...= 1, 2, 3
    local b = a  -- now b = 1, *not* 1, 2, 3

and tuples can not be passed as arguments:

    func(a)  -- this equals func(1, 2, 3)
    func(a, "aap")  -- this equals func(1, "aap")

As a consequence a tuple can never appear as an entry
in a table or another tuple.  In this particular form,
this would undermine your `caching function' example. 
What would be needed in this approach is that tuples
could be used as table keys/values.

    local a = {}
    a[1, 2] ...= "aap", "noot
    print(a[1,2])  -- aap  noot

Implementation challenges aside, this would also need
some new approach to table iteration...

No need for tuples as tuple entries I'd say...

--
Wim


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com