-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for freezing of containers #35
Comments
I really hope that this is possible, because it is how I would like to use most O(1) lookup functions. |
@gregorycollins what are your thoughts on this? If you think this is OK, I might take a look at actually implementing this. |
My thought is, I don't really know how to do it cleanly so I haven't implemented it yet, and the use case hasn't seemed compelling enough to make the work feel worth it. All of the data types need to be reworked for pure lookup, but you want to use the same lookup algorithms everywhere, so you either have to duplicate everything or use templating/code generation. One possibility you could consider is just to newtype around hashtables in IO, and use |
The use case is to build the hash table kust once in ST and then use it in pure code just for lookups without having to wrap the pure code in a monad. I actually think of something similar - a newtype wrapper and runST'ing the existing lookup function. |
My point is that you can already do this, with build
:: HashTable h
=> Maybe Int -- ^ size hint
-> (h s k v -> ST s ())
-> ST s (Pure.HashTable k v) Pure.HashTable can just be a set of lambdas doing either data HashTable k v = HashTable { _lookup :: k -> Maybe v, ... } The extra safety comes from swapping out the |
P.S. build
:: HashTable h
=> Maybe Int
-> (IOHashTable h k v -> IO ())
-> IO (Pure.HashTable k v) |
Would it be possible to add support to freeze the container - creating a read only copy which can be queried outside monad.
The text was updated successfully, but these errors were encountered: