-
Notifications
You must be signed in to change notification settings - Fork 64
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
Wrapped sets and maps #171
Comments
What would these look like? What would be the advantage for the user? |
I'm not sure what you mean about what they'd look like. For the wrapped map case, the purpose would be to let libraries depending on this one magically turn their map implementations into set implementations. Applications the other way are definitely not as obvious. |
I mean what are you proposing as the newtype wrapper here? I'm not sure what practically benefit you're going for here. Is the idea to get to elide definitions of data types like |
Sounds about right. newtype WrappedMap m = WrappedMap {unwrappedMap :: m}
newtype HashSet a = HashSet (WrappedMap (HashMap a ()))
deriving ({- all the instances -}) |
What's the purpose of the |
It's just a target for GND. The relationship between a set of |
Obviously |
Arguments on principle aren't really too interesting to me, I'm sorry. I'm much more interested in code being useful in some kind of real-world case. |
A map from elements of type
k
to()
can be viewed as a set. Indeed, this is howData.HashSet
works. Less usefully, I imagine, a set of elements of typek
can also be viewed as a map from elements of typek
to()
. Should we offernewtype
wrappers implementing this correspondence?The text was updated successfully, but these errors were encountered: