Peter Schuller writes:
> I can turn 'get' into 'peek' and have another function that more
> specifically advertises, by its name, that it produces both a value
> and a new cache. That only helps naming though, and not usability of
> said function.
Yes, and though it does so for a completely diff
I think what you are doing is analogous to the peek and pop operations in
core.
To get and remove and item you would peek to get the first item, and then
alter your ref with a pop, which returns the structure minus with the first
item removed.
If you do all of this within a dosync, including the
This might be of related interest:
http://kotka.de/blog/2010/03/The_Rule_of_Three.html
On Jul 17, 3:19 pm, Peter Schuller
wrote:
> Another thing occurred to me: While not necessarily important in the
> cache of an LRU cache, one might want a data structure, even if it
> tends to be used in a side
Another thing occurred to me: While not necessarily important in the
cache of an LRU cache, one might want a data structure, even if it
tends to be used in a side-effectful manner, to participate in STM
co-ordinated transactions. If one hides an underlying ref, this means
that either callers do not
> Assuming there is a legitimate need for a persistent data structure
> (such as for concurrent background introspection purposes), what would
> be your favored approach in terms of an interface?
I should clarify that no, I'm not really willing to use a state monad
since I'm trying to figure out t
>> lru-peak -> [value]
>
> I take it you meant "peek", not "peak".
Yes - Yes. How embarrassing ;) Thanks.
>> One possibility I was thinking of was that, since the expected use
>> case of an LRU cache is so specific, it may be acceptable to have the
>> lru "library" itself provide a side-effect
Peter Schuller writes:
> lru-peak -> [value]
I take it you meant "peek", not "peak".
[...]
> One possibility I was thinking of was that, since the expected use
> case of an LRU cache is so specific, it may be acceptable to have the
> lru "library" itself provide a side-effect aware interface
Hello,
I wrote a persistent LRU cache, but I'm not sure I am satisfied with
the interface in particular (and perhaps the implementation). It's at:
http://github.com/scode/plru
git://github.com/scode/plru.git
(Btw in general I'd appreciate any feedback - especially negative
about the implem
