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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
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