parse failures accepted by GHC

[sebf@…]

The attached module is a collection of examples that can be parsed by GHC but lead to a parse failure in haskell-src-exts-0.5.4.

[anonymous]

I wasn't allowed to attach the file without an account, so here it is inline:

> {-# LANGUAGE TypeFamilies #-}

{-# LANGUAGE KindSignatures #-} -- avoids third parse failure


What I encountered when testing haskell-src-exts-0.5.4
======================================================

GHC can parse this module. I don't know which of the examples are bugs
in HSE and which are accepted by GHC although they are not valid
Haskell.


Multiple class contexts
-----------------------

HSE complains about multiple class contexts in type signatures.

> multipleCtx :: Eq a => Show a => a
> multipleCtx = undefined


'Prelude.read: no parse'
------------------------

Errors in derived read instances should be caught to give a more
useful error message. I encountered this when using the (hopefully
soon deprecated) LANGUAGE pragma NoMonoPatBinds.


Kind signatures for type families
---------------------------------

In GHC, the TypeFamilies pragma seems to imply KindSignatures, in HSE
it doesn't. The following line yields a parse failure in HSE if the
TypeFamilies pragma is set but KindSignatures are not allowed
explicitly.

> type family WithKindSig (a :: * -> *)


Qualified usage of `(.)`
------------------------

While HSE happily parses `(Prelude.++)` it fails to parse it if the
used operator is `(.)`.

> twoDots = (Prelude..)


nested as-patterns
------------------

This example is accepted if we either drop the outer list brackets or
replace `(Just _)` with `True`. Otherwise, HSE complains that
RegularPatterns are not enabled.

> nestedAsPat [x@(Just _)] = undefined

[nibro]

Thanks for reporting!

#1 is not valid Haskell98 syntax and should rightly be exluded. If GHC accepts it without relevant flags then GHC is at fault. However, there's a real HSE bug hiding here. If the second context is parenthesised, i.e.

multipleCtxt :: Eq a => (Show a => a)

then HSE accepts it even without e.g. Rank2Types, whereas the signature without parentheses is rejected by HSE even if Rank2Types is enabled. HSE's behavior should probably be the same with or without the parenthesis, and should exclude the type in both cases with no flags, and accept it in both cases when Rank2Types is not on.

#2 is not a bug but a feature request, one which I definitely agree with.

#3 is undocumented behavior in GHC (surprise surprise). I do think it makes sense that TypeFamilies? implies KindSignatures?, but I really wish these issues were more clearly defined. I will implement it though.

#4 and #5 are both clear bugs in HSE.

I will open separate tickets for each of these.

[nibro]

This ticket is now superceded by tickets #37, #38, #39, #40 and #41.