-
Notifications
You must be signed in to change notification settings - Fork 721
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
Add Tx and Block pattern synonyms #2286
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good. A couple minor suggestions below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I accidentally resolved a couple of comments.
Since this is the API I thin we should aim for the simplest, easiest to understand code we can get. What we have in the PR is not it.
-- | A block consists of a header and a body containing transactions. | ||
-- | ||
pattern Block :: BlockHeader -> [Tx era] -> Block era | ||
pattern Block header txs <- (getBlockHeaderAndTxs -> (header, txs)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the alternatives to this? Why ViewPatterns
? Should we not be aiming for simple code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're attempting to hide away internal representations in data Block era
, and present a simplified representation here: a block is just a block header and some transactions. Eventually we should probably not export the other constructor of Block
except is some sort of Internal
module.
An alternative to this is to keep Block
abstract and provide projection functions i.e. export getBlockHeaderAndTxs
or similar.
There are some advantages to using a pattern synonyms. It indicates to users that this is in some sense a "complete" pattern (GHC is smart enough to see this is complete). The pattern also appears in the same place as constructors in the haddocks. This is more inline with a "closed world" design meaning users can just rely on pattern matching rather than having to search for projection functions. We also seem to use pattern synonyms already in various parts of cardano-api.
@dcoutts, perhaps you want to chime in on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that in general view patterns are horrid, and we don't use them generally.
To use (non-trivial) pattern synonyms (which is sensible here) we're forced to use view patterns. It's a very limited use. It doesn't infect anything else.
@@ -6,6 +6,7 @@ | |||
{-# LANGUAGE ScopedTypeVariables #-} | |||
{-# LANGUAGE TypeApplications #-} | |||
{-# LANGUAGE TypeFamilies #-} | |||
{-# LANGUAGE ViewPatterns #-} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why. I have never seen a case where using ViewPatterns
has resulted in easier to read or easier to understand code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you buy into exposing pattern synonyms, then we're forced to implement them with view patterns in order to use projection functions.
7d8ad57
to
44b57a3
Compare
I should not comment on PRs at the end of a 12 hour day
bors merge |
Build succeeded: |
No description provided.