Dear Cafe, in containers, we have Data.IntMap/IntSet . Because of the underlying implementation (patricia trees), keys/elements indeed have to be Int (we need their bits). This is a conflict with type-safety: I try to avoid Int, and use some newtype T = T Int instead. E.g., I want to distinguish several different indices for the same structure, like row and column numbers in (sparse) matrices, or vertices in bipartite graphs. So, I made these trivial wrappers EnumMap and EnumSet: https://github.com/jwaldmann/satchmo-solver/tree/master/src/Data Is this reasonable (do from/toEnum really have zero cost)? Would this be a useful addition to containers? - J.W.
Wouldn't you get the same result with using unordered-containers and a Hashable instance for your Enums? See: https://hackage.haskell.org/package/hashable-1.2.2.0/docs/Data-Hashable.html... Patrick On Tue, Mar 31, 2015 at 6:42 PM, Johannes Waldmann < waldmann@imn.htwk-leipzig.de> wrote:
Dear Cafe,
in containers, we have Data.IntMap/IntSet . Because of the underlying implementation (patricia trees), keys/elements indeed have to be Int (we need their bits).
This is a conflict with type-safety: I try to avoid Int, and use some newtype T = T Int instead. E.g., I want to distinguish several different indices for the same structure, like row and column numbers in (sparse) matrices, or vertices in bipartite graphs.
So, I made these trivial wrappers EnumMap and EnumSet: https://github.com/jwaldmann/satchmo-solver/tree/master/src/Data
Is this reasonable (do from/toEnum really have zero cost)? Would this be a useful addition to containers?
- J.W.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Hi.
Independently of your proposal, there already is
https://hackage.haskell.org/package/EnumMap
Cheers,
Andres
On Tue, Mar 31, 2015 at 7:42 PM, Johannes Waldmann
Dear Cafe,
in containers, we have Data.IntMap/IntSet . Because of the underlying implementation (patricia trees), keys/elements indeed have to be Int (we need their bits).
This is a conflict with type-safety: I try to avoid Int, and use some newtype T = T Int instead. E.g., I want to distinguish several different indices for the same structure, like row and column numbers in (sparse) matrices, or vertices in bipartite graphs.
So, I made these trivial wrappers EnumMap and EnumSet: https://github.com/jwaldmann/satchmo-solver/tree/master/src/Data
Is this reasonable (do from/toEnum really have zero cost)? Would this be a useful addition to containers?
- J.W.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
@Andres
I was not aware. But that looks like an actual copy of the IntMap code, so it does not get maintained/updated? That's why I was thinking of a wrapper module only. @Patrick
the same result with using unordered-containers and a Hashable instance?
type-wise, yes, but it's a different implementation, so "same performance" should be benchmarked. - J.W.
Dear Johannes, On 31/03/15 19:06, Johannes Waldmann wrote:
@Andres
I was not aware. But that looks like an actual copy of the IntMap code, so it does not get maintained/updated? That's why I was thinking of a wrapper module only.
There's also https://hackage.haskell.org/package/enummapset https://wiki.haskell.org/EnumSet_EnumMap so this must be a good idea, since it's come up so many times. :-) I've not looked at the performance overhead of this approach, but I have used something quite similar, which uses Coercible instead of Enum. Of course, that works only for newtypes of Int, but it is guaranteed to be zero-cost. Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/
Adam Gundry
Ah. That's the wrapper I want.
so this must be a good idea, since it's come up so many times.
Can we then please put it in containers? NB: The name (EnumMap) seems wrong, though. The module will be imported qualified anyways, so the type should just be Map. Then, changing the implementation (if the key type implements Ord, Enum, and Hashable) is really just changing the import. But then, it's at least consistently wrong - e.g., in line with Data.HashMap. Thanks, Johannes.
participants (4)
-
Adam Gundry -
Andres Löh -
Johannes Waldmann -
Patrick Chilton