-
Notifications
You must be signed in to change notification settings - Fork 23
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
[FR] - Use classy era constraints in generators. #702
Comments
They're both practically interchangeable. What's the rationale for this change? |
The rational is that we are using these generators downstream, and providing the argument, when we want to construct say a validity interval, seems like unnecessary noise when it can be inferred from the era type. |
1 similar comment
The rational is that we are using these generators downstream, and providing the argument, when we want to construct say a validity interval, seems like unnecessary noise when it can be inferred from the era type. |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 120 days. |
Having an era just on a type level seems like an inconvenience when working with multiple eras. See this test for example:
How would you rewrite it without value level era witnesses generators? This des not seem to work for me: let genCert' :: IsShelleyBasedEra era => H.Gen (Certificate era)
genCert' = genCertificate shelleyBasedEra
AnyShelleyBasedEra (sbe :: ShelleyBasedEra era) <- H.forAll H.enumBounded
cert1 <- H.forAll $ genCert' @era
|
Yeah I think I agree with this now. |
In the hedgehog generators we have generators such as
I think without loss of generality these could all be the type class versions
The text was updated successfully, but these errors were encountered: