I've wanted to try using the high bit of the length of an array (eg the sign bit) as a lock bit as an alternative c. I think that would allow objects to cheaply validate whether an array should not be modified (since it would simply reuse the inbounds check), but also be easy to mask off when looking at the length. I wasn't sure if this would really work, or whether others thought it would be worthwhile.
On Monday, October 13, 2014, Stefan Karpinski <[email protected]> wrote: > Yeah, it's a bit sketchy, but the alternatives are: a) only allow > immutable values as keys, which seems annoyingly finicky; or b) hash > mutable values by identity, which seems really unintuitive. You can think > of using a value as a dict key, as an implicit promise not to mutate it. > Copying keys before storing them in dicts doesn't really solve the problem > since you can still get a hold of the copy that's stored and mutate that; > this is only slightly harder to do. > > On Mon, Oct 13, 2014 at 12:07 PM, Tamas Papp <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> As a Julia newbie, I see no problem with that. Modifying the keys of a >> hash table is an operation with undefined consequences ("just don't do >> it"), so the programmer should focus on good practices that prevent this >> from happening (it is not that hard). >> >> The alternative is to only allow bits types or containers which are >> immutable recursively (eg an immutable type which contains a mutable >> container is ruled out). In practice, this can be done, bit it would >> lead to a lot of boilerplate in case wants to use other types as keys. >> >> Best, >> >> Tamas >> >> On Mon, Oct 13 2014, nbbb <[email protected] >> <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: >> >> > as a julia outsider (for now), it seems odd to me that mutable >> containers >> > are allowed as dictionary keys at all. >> >> >
