Skip Menu |
Report information
Id: 124016
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: smls75 [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: Rakudo inappropriately uses .gist for caching "is cached" sub arguments; needs proper solution
Download (untitled) / with headers
text/plain 1.6k
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.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.9k
On Sun Mar 08 07:02:33 2015, smls75@gmail.com wrote: Show quoted text
> 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.
Since there was no obvious solution in sight, and there were other issues with "is cached", we've decided to defer this functionality to a future Perl 6 language version. So, removing it from the xmas list.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org