Steve, Sorry, I probably wasn't as explicit as I could have been.
I believe that providing an automatic way of updating a dictionary would be challenging. What I was suggesting is that a function be provided which allows a user to fix up a dictionary after modifying key, which is not currently possible, but would be possible using Tokens. Cheers, Kevin On Mon, Oct 13, 2014 at 12:18 PM, <[email protected]> wrote: > Kevin, > > I agree that if the user decides to update a mutable key by accessing it > through a token, then the container has enough information to patch up its > indexing structure and keep it valid. However, in the trace of a Julia > execution in my original posting, the user clobbered a key inside the > dictionary DD via the statement a[3]=9, which makes no reference at all to > the dictionary. In this scenario it is not clear how the container can > stay consistent. > > -- Steve > > > On Monday, October 13, 2014 2:26:14 PM UTC-4, Kevin Squire wrote: >> >> I'll point out that part of Steven's proposed SortedDict implementation >> supports "Tokens", which represent the location of a (key, value) pair in a >> dictionary. These are generalizable to hash-based Dicts, and should make >> it possible to update the dictionary when a key is changed. >> >> For hash-based dictionaries, the main concern is keeping track of the >> validity of tokens when the hash table is resized. >> >> Cheers, >> Kevin >> >> On Monday, October 13, 2014, Ivar Nesje <[email protected]> wrote: >> >>> I think the easy access to user defined immutables in Julia would make a >>> great argument for disallowing mutable keys. It's an unfortunate choice to >>> make tough, because it is a pure restriction that makes some problems >>> harder to solve. It also seems somewhat costly in implementation (because >>> we need to check a new recursive immutable property). The result will be >>> that lots of users gets a error about mutable keys, instead of a KeyError >>> only when the key changed. >>> >>> We could make a copy on insertion, but that would require us to also >>> take a copy before iterating on the keys as well. That would create lots of >>> temporary copies, that Julia currently doesn't have the infrastructure to >>> optimize away. >>> >>> Ivar >>> >>> kl. 19:12:37 UTC+2 mandag 13. oktober 2014 skrev Stefan Karpinski >>> følgende: >>>> >>>> Yeah, there's no ideal solution. Python disallows mutable keys; Ruby >>>> allows them and has the same behavior as Julia here; Perl turns all keys >>>> into strings (I think that string keys may still be mutable in Perl, but >>>> it's become so hard to get a readline-enabled prompt in Perl, that I gave >>>> up on checking). >>>> >>>>> >>>>> >>>>
