-
Notifications
You must be signed in to change notification settings - Fork 563
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
Make forall keyword optional in instance declaration #4051
base: master
Are you sure you want to change the base?
Conversation
I would prefer not to make a change where the |
I'm unsure which type of error this would be. Is it one of these or a new type of error?
|
I'd say it should be a new error, since it's for an instance rather than a kind or type. |
Something like QuantificationCheckFailureInInstanceHead? |
I'd suggest QuantificationCheckFailureInInstance. The phrase "instance head" sometimes refers to the entire part of the instance to the right of the |
Is the type non-terminal wanted before contraints "=>" or would that accept too much? |
You don't want the production to be All you want to add to the production is |
The complication I'm running into with the |
Locally, the right thing to do is probably to add another field to |
Alternatively, you could try blowing that encoding up and actually accepting any type in an instance head, but that might be more ambitious? I don't know what would happen if you tried that, and you might need to add in some extra errors somewhere else corresponding to the types that previously wouldn't parse. |
Thanks @rhendric. I'll try option one first. Two questions:
|
|
I'm trying to wrap my head around this so I can write good test cases but I can't think of a scenario where this would help catch a typo. I've tried two different ways, but in both examples the compiler already generates an error so I don't understand what adding forall syntax provides here. Can you please provide an example of situation forall syntax could help catch a typo? Examples (borrowed from @michaelficarra),
|
The point is to generate an error which is more likely to help the user diagnose the problem as quickly as possible. While it is true that we do already generate an error in those cases, the point remains that it would often be more useful to generate a different one. If that’s not persuasive enough then how about this: class IsPositive number result
class IsPrime number result
instance checkPrimality ::
( IsPositive number True
, -- [... other constraints to check whether `number` is actually prime ...]
) => IsPrime nubmer True In which we are accidentally declaring that all numbers - even nonpositive ones - are prime due to a typo, because this primality test exists only at the type level and there are no term level expressions to help the compiler realise that something is off. |
Thanks @hdgarrood. So adding forall to it like this -- class IsPositive number result
class IsPrime number result
instance checkPrimality :: forall number.
( IsPositive number True
, -- [... other constraints to check whether `number` is actually prime ...]
) => IsPrime nubmer True the compiler should generate error similar to how it would if it happened at the function level-- Is this the expectation? |
Yes, that's exactly right. |
I added a new function, Just typeClass -> do
checkInstanceArity dictName className typeClass tys
(deps', kinds', tys', vars) <- withFreshSubstitution $ checkInstanceDeclaration moduleName (sa, deps, className, tys)
traverse_ checkTypeQuantificationInInstance tys'
tys'' <- traverse replaceAllTypeSynonyms tys' Problem is that tys' only contains the name of type implementing the typeclass -- 'nubmer' in code snippet provided by @hdgarrood. I assume that I will need to check that 'nubmer' is listed as one of the types in forall part, but I don't know how to get this. It looks like I'd need to add a new |
You might be better off adding a |
For a test, I tried adding my quantification variable to the freeVars in
|
It's been awhile, but I'm back. @rhendric @garyb I have a passing test but not failing test. Couple questions:
|
Welcome back 😄 I would say 1 is a warning, 2 is an error. |
Just FYI. |
@garyb @JordanMartinez |
tests/purs/failing/1120.purs
Outdated
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.
There should be a failure output for this test. Could you push and commit that?
Also, I'd expect there to be 3 lines of -- @shouldFailWith ...
, one for each error.
tests/purs/warning/1120.purs
Outdated
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.
Similarly here, there should be a corresponding .out
file. Can you commit and push that?
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.
Will do. I'm guessing this will be easier to add once the compiler actually spits out an error :-D.
Not sure if this works or not but, is there a warning for a shadowed type variable?
|
CHANGELOG.md
Outdated
@@ -1453,6 +1453,7 @@ Other improvements: | |||
The previous `logo.png` was not legible against a dark background (#4001). | |||
|
|||
* Show the constraints that were being solved when encountering a type error (@nwolverson, #4004) | |||
* Made the forall keyword optional in the instance header but gives warning if it is missing (@jrairigh, #1120) |
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.
This line is out-of-date. Could you remove it and follow the directions in CHANGELOG.d/README.md
?
Seems like reasonable assumption, but I entered this code into PSCi and it didn't give a warning.
|
Made the forall keyword optional in the instance header but gives warning if it is missing #1120. This change does not modify the actual meaning of the code. To do that, I believe the InstanceHead type would need to include a TypeForall type. This is a more difficult change than the ask for #1120, so hoping this can be worked in a separate issue.