Suggest -XExistentialQuantification for 'forall' in data declarations
D5180 introduced a slight regression to the error messages. In this code
data T = forall a. MkT aGHC used to complain
rnfail053.hs:5:10:
Not a data constructor: ‘forall’
Perhaps you intended to use ExistentialQuantificationbut then the message has become
rnfail053.hs:5:18: error:
Illegal symbol '.' in type
Perhaps you intended to use RankNTypes or a similar language
extension to enable explicit-forall syntax: forall <tvs>. <type>Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |
Activity
added Ttask Trac import parser labels
I'm especially interested in this ticket because I recently implemented a prototype of the forall-always-a-keyword-in-types proposal, and to my surprise, this caused the stderr for
rnfail053to change even further:diff -uw "rename/should_fail/rnfail053.run/rnfail053.stderr.normalised" "rename/should_fail/rnfail053.run/rnfail053.comp.stderr.normalised" --- rename/should_fail/rnfail053.run/rnfail053.stderr.normalised 2019-02-13 06:48:37.043855139 -0500 +++ rename/should_fail/rnfail053.run/rnfail053.comp.stderr.normalised 2019-02-13 06:48:37.043855139 -0500 @@ -1,5 +1,7 @@ rnfail053.hs:5:10: - Illegal symbol ‘forall’ in type - Perhaps you intended to use RankNTypes or a similar language - extension to enable explicit-forall syntax: ‘forall <tvs>. <type>’ + Data constructor ‘MkT’ has existential type variables, a context, or a specialised result type + MkT :: forall a. a -> T + (Enable ExistentialQuantification or GADTs to allow this) + In the definition of data constructor ‘MkT’ + In the data type declaration for ‘T’It wasn't clear to me at the time whether this was an upgrade or downgrade in error message quality, so I worked around it by making this change to the parser:
diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y index 820144d930..e3423669bf 100644 --- a/compiler/parser/Parser.y +++ b/compiler/parser/Parser.y @@ -2275,7 +2293,11 @@ constr :: { LConDecl GhcPs } (fst $ unLoc $2) } forall :: { Located ([AddAnn], Maybe [LHsTyVarBndr GhcPs]) } - : 'forall' tv_bndrs '.' { sLL $1 $> ([mu AnnForall $1,mj AnnDot $3], Just $2) } + : 'forall' tv_bndrs '.' {% do { hintExplicitForall $1 + ; pure $ sLL $1 $> + ( [ mu AnnForall $1 + , mj AnnDot $3 ] + , Just $2) } } | {- empty -} { noLoc ([], Nothing) }That reverted the error message back to what it was before (mentioning
RankNTypes). But perhaps the error message really ought to mentionExistentialQuantification.Some related questions: there are currently two distinct error messages that mention not enabling
ExistentialQuantification:- There's the one in the original description of this ticket (the "
Not a data constructor: ‘forall’" one). - There's also the one I mentioned in this comment (the "
has existential type variables, a context, or a specialised result type" one).
Do we need both? Or is there a way we could consolidate the two somehow? Would the answer change if we made
forallpermanently a keyword in types?- There's the one in the original description of this ticket (the "
Do we need both? Or is there a way we could consolidate the two somehow? Would the answer change if we made forall permanently a keyword in types?
No, we don't need both, and the
forallproposal makes the matters trivial. See !363 (merged)changed milestone to %8.8.1
Landed in 887454d8889ca5dbba70425de41d97939cb9ac60.
Trac metadata
Trac field Value Test case - → rename/should_fail/rnfail053 mentioned in issue #16339 (closed)
added backport label
added Pnormal label
