|Subject:||Rakudo inappropriately uses .gist for caching "is cached" sub arguments; needs proper solution|
In current Rakudo, the 'is cached' trait for routines compares incoming argument lists by their .gist representation. This was probably done as a temporary work-around, and is not a satisfactory solution because: * .gist elides information (e.g. cutting off lists/arrays after the first few elements), thus causing false positives. * .gist is explicitly meant as a summary for human consumption, and not for hashing/comparing objects. IRC discussion of the problem: masak: 'is cached' does some "snapshotting" of the incoming maybe-reference value, and it's that thing that's being eqv-compared with what's in the cache. (though right now it's being .gist-compared, which may or may not be goodenuf) smls: well, seeing how gist truncates lists/arrays, it seems a little unsafe masak: yes, that's a *bug* masak: actually, knowing that, using .gist in the first place is *wrong*, because the story for .gist is "string summary for human/screen consumption", not "exact eqv-like value for things like hashing" IRC discussion about what a proper solution might look like: TimToady: I think each immutable type should have a hash function of some sort, and mutable types a way to snapshot to eqv semantics masak: that sounds good so far, but I think we need more than that. TimToady: well, and a well-defined stragegy for combining hashes masak: also, some things (like filehandles) probably don't have a good immutable/eqv representation. TimToady: for filehandles and VAR($x) hashing the WHICH is probably as good as we can do masak: right. that has to be an allowable fallback.