Expression/command ambiguity resolution

This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
introducing a new ambiguity resolution system in the parser.

Problem: there are places in the grammar where we do not know whether we
are parsing an expression or a command:

	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
	proc x -> do { (stuff) }        -- 'stuff' is a command

Until we encounter arrow syntax (-<) we don't know whether to parse
'stuff' as an expression or a command.

The old solution was to parse as HsExpr always, and rejig later:

	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)

This meant polluting 'HsExpr' with command-related constructors. In
other words, limitations of the parser were affecting the AST, and
all other code (the renamer, the typechecker) had to deal with these
extra constructors by panicking.

We fix this abstraction leak by parsing into an intermediate
representation, 'ExpCmd':

	data ExpCmdG b where
	  ExpG :: ExpCmdG HsExpr
	  CmdG :: ExpCmdG HsCmd

	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))

	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
	checkExp f = f ExpG  -- interpret as an expression
	checkCmd f = f CmdG  -- interpret as a command

See Note [Ambiguous syntactic categories] for details.

Now the intricacies of parsing have no effect on the hsSyn AST when it
comes to the expression/command ambiguity.

Future work: apply the same principles to the expression/pattern
ambiguity.

1 files changed, 2 insertions, 1 deletions

diff --git a/mk/config.mk.in b/mk/config.mk.in
index 0119e9a984..2bff8432e4 100644
--- a/mk/config.mk.in
+++ b/mk/config.mk.in
@@ -852,7 +852,8 @@ HAPPY_VERSION		= @HappyVersion@
 #
 # Options to pass to Happy when we're going to compile the output with GHC
 #
-SRC_HAPPY_OPTS		= -agc --strict
+# TODO (int-index): restore the -c option when happy/pull/134 is merged.
+SRC_HAPPY_OPTS		= -ag --strict
 
 #
 # Alex