Expression/command ambiguity resolution

Authored by int-index on Feb 1 2019, 11:03 AM.


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


Marge Bot <>Feb 23 2019, 8:37 PM
rGHC6cce36f83aec: Add AnonArgFlag to FunTy
Marge Bot <> committed rGHCe61f6e35e2ff: Expression/command ambiguity resolution (authored by int-index).Feb 23 2019, 8:37 PM