I think it's reasonable too! There are advantages to all these schemes.
I was particularly impressed by your arguments about the way "value
semantics" are used in other parts of Python, something I didn't
consider. It is the case that Icon uses a specific mix of "value" and
"pointer" rules for dictionary resolution, but Icon also uses that same
mix of rules in its other comparison contexts (membership testing, its
"===" equality predicate, selecting which "case" clause applies).
On third thought I'm convinced this kind of consistency is worth more
than anything else.
> I strongly believe that tuples should be treated as values, not as
> objects. Consider a function of two arguments that is rather
> expensive to calculate. This function could maintain a dictionary of
> previously calculated function values and return values from there if
> available, like this:
>
> known = {}
> def f(a, b):
> if known.has_key((a,b)): return known[(a, b)]
> x = real_f(a, b)
> known[(a, b)] = x
> return x
Just noting that it's easy enough to fake given object semantics too.
E.g., assuming a & b are numbers & Python's dictionaries have been
extended to support indexing by numbers:
known = {}
def f(a,b):
if known.has_key(a):
a_vals = known[a]
if a_vals.has_key(b): return a_vals[b]
else:
known[a] = a_vals = {}
a_vals[b] = x = real_f(a, b)
return x
For this probably-common kind of use, I sure agree that value semantics
allow a simpler solution (really, there's no need to trot out a function
with three arguments <grin>).
> ...
> It is true that this doesn't work for your example of a library
> routine that needs to be able to traverse *arbitrary* circular data
> structures; but a built-in function returning the address of an object
> as integer would be a good alternative (so you can still build a
> dictionary keyed on object identity).
Agreed again -- so how about adding that function <smile>?
> Regarding lists and dictionaries, the problem is this: if possible I
> would like to support value semantics for those, but the implementation
> makes this too difficult.
That's cool. I think we agree there _are_ clear uses for lists & dicts,
as dict indices, provided object semantics are used. I think we agree
too (me belatedly) that value semantics are more natural for Python. But
I'm _not_ sure value semantics for lists & dicts, as dict indices, would
be useful enough to be worth the pain of implementing.
I do note that various LISPs implement dictionaries as "association
lists", and that the usual access function "assoc" uses the "equal"
predicate to see whether a key is present; and "equal" does usually
compare deep structure (with undefined behavior in the presence of
loops). Any LISP'ers out there who think that's important to do?
can't-say-i've-seen-it-used!-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp