Replies: 1 comment 2 replies
-
I've been using Barbies for this, so that the unbundled type can have no wrappers on the field types: https://github.com/gergoerdi/retroclash-lib/blob/master/src%2FRetroClash%2FBarbies.hs |
Beta Was this translation helpful? Give feedback.
2 replies
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
-
One annoyance that I sometimes encounter is impedance mismatches due to the dual treatment of products in Clash. That is, a product can be represented as either a signal-of-a-product or as a product-of-signals (which are isomorphic as witnessed by
Bundle
). Under the status quo, product types will generally favor one of these representations, with the other being rather represented as a tuple. This asymmetry is awkward and compromises type safety.A pattern that I have used in my projects is to represent products as higher-kinded type. For instance, one might have a simple product:
where one can then provide a
Bundle
instance:I have been tempted to write a TH splice to derive such instances in the past.
Of course, this is a slightly unfortunate tradeoff as we must now manually wrap/unwrap
Identity
s whenever working with the bundled type. I often find myself minimizing this syntactic overhead by locally bindingmkI = Identity
andunI = runIdentity
.However, another design would be to provide pattern synonyms to handle the common bundled case:
This is another tricky set of trade-offs as now we rely on the
DuplicateRecordFields
andPatternSynonyms
extensions. Is this worth it? I don't know.Have others thought about this problem? Is there a nicer solution that I have missed?
Beta Was this translation helpful? Give feedback.
All reactions