[Haskell-cafe] Void vs ()
Bardur Arantsson
spam at scientician.net
Fri Mar 24 21:23:40 UTC 2017
Hi all,
[Context: I'm working on a CQRS/ES library and in the following, "i" is
an identifier for an aggregate root, "e" is an event type, and the "Int"
is a sequence number.]
So, I have a data type
data Foo i e = Foo i e Int
where I want to have a corresponding
data Batch i e = Batch i [Foo x e Int]
(I'll come back to "x". It's just a metasyntactic variable for now.
The point of the "Int" is that it's extra information that I really
need to keep, but it's not essential to the Foo data structure
itself.)
with an operation
batchFoos :: [Foo i e] -> [Batch i e]
batchFoos = ...
(basically a standard Data.List.groupBy
where I compare for equality on the i's.)
I also have an extraction function
toList :: Batch i e -> (i, [Foo x e Int])
My question is then: What's the best thing to use for "x", Void or ()?
The idea behind "collapsing" the "i" parameter away to an "x" is to
signal to users to the API that they can be absolutely certain that when
they call "toList", they can be sure that all the Foo's that they get
back have the same i value, namely the one which is the first component
of the tuple.
An alernative I've been considering is actually to create a Foo' type
which actually does eliminate the i parameter, but it seems a bit
boilerplatey. (It's not a *lot* of code to duplicate, so if it looks
like the best option, I'll do that... but it feels odd.)
Anyone have any suggestions on what the best way to approach this would be?
(Aside: AFAICT there's no reasonable way to implement anything like
Foldable or Traversable to avoid the explicit "toList" function, right?
AFAICT Foldable/Traversable constrain you to using the *actual* last
type parameter, "e", for folding over. Are there any generic alternative
type classes that let you "pick your own element type"? I'm guessing
Traversal could possibly be that, but if I have to incur a Lens
dependency, I'll just live with a "toList" function. This is just about
whether it can be done elegantly -- it's not a big deal.)
Regards,
More information about the Haskell-Cafe
mailing list