Skip to content
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

Merged
merged 1 commit into from
Jan 20, 2021
Merged

Conversation

DavidEichmann
Copy link
Contributor

No description provided.

Copy link
Contributor

@dcoutts dcoutts left a 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.

cardano-api/src/Cardano/Api/Block.hs Outdated Show resolved Hide resolved
cardano-api/src/Cardano/Api/Block.hs Outdated Show resolved Hide resolved
cardano-api/src/Cardano/Api/Block.hs Show resolved Hide resolved
erikd
erikd previously requested changes Jan 19, 2021
Copy link
Contributor

@erikd erikd left a 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.

cardano-api/src/Cardano/Api/Block.hs Outdated Show resolved Hide resolved
-- | 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))
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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 #-}
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@DavidEichmann DavidEichmann force-pushed the dcoutts/api-block-patterns branch from 7d8ad57 to 44b57a3 Compare January 19, 2021 11:25
@erikd erikd dismissed their stale review January 19, 2021 22:28

I should not comment on PRs at the end of a 12 hour day

@dcoutts
Copy link
Contributor

dcoutts commented Jan 20, 2021

bors merge

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Jan 20, 2021

@iohk-bors iohk-bors bot merged commit cd19d38 into master Jan 20, 2021
@iohk-bors iohk-bors bot deleted the dcoutts/api-block-patterns branch January 20, 2021 11:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants