[GHC] #5333: Arrow command combinators and infixr cause the desugarer to fail
GHC
cvs-ghc at haskell.org
Thu Jul 21 18:35:05 CEST 2011
#5333: Arrow command combinators and infixr cause the desugarer to fail
----------------------------------+-----------------------------------------
Reporter: peteg | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler (Parser) | Version: 7.0.3
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
----------------------------------+-----------------------------------------
Comment(by simonpj):
Thanks Ross. Adding a whole new pass just to deal with this very special
case isn't very attractive.
In fact, I've moved sharply away from these "syntax tables" in the rest of
the compiler. As you'll see, the ''only'' use of `SyntaxTable` is on a
`HsCmdTop`, and I'd love to be rid of it. Instead, in (say) monad
comprehensions, the necessary operators are attached directly to the
`HsStmt` constructors, see the `SyntaxExpr` arguments in `StmtLR` (in
`HsExpr`) for example. This would mean the problem reported here simply
would not arise.
This would not as straightforward for arrows, because in effect we hijack
a bunch of `HsExpr` constructors for use in arrow abstractions (see line
600ff of `HsExpr`), which says
{{{
The legal constructors for commands are:
= HsArrApp ... -- as above
| HsArrForm ... -- as above
| HsApp (HsCmd id)
(HsExpr id)
| HsLam (Match id) -- kappa
-- the renamer turns this one into HsArrForm
| OpApp (HsExpr id) -- left operand
(HsCmd id) -- operator
Fixity -- Renamer adds fixity; bottom until then
(HsCmd id) -- right operand
| HsPar (HsCmd id) -- parenthesised command
| HsCase (HsExpr id)
[Match id] -- bodies are HsCmd's
SrcLoc
| HsIf (Maybe (SyntaxExpr id)) -- cond function
(HsExpr id) -- predicate
(HsCmd id) -- then part
(HsCmd id) -- else part
SrcLoc
| HsLet (HsLocalBinds id) -- let(rec)
(HsCmd id)
| HsDo (HsStmtContext Name) -- The parameterisation is
unimportant
-- because in this context we
never use
-- the PatGuard or ParStmt variant
[Stmt id] -- HsExpr's are really HsCmd's
PostTcType -- Type of the whole expression
SrcLoc
}}}
I'm not keen on adding extra fields to all of these constructors.
Actually I think it might be best simply to make a new data type for
arrows, with these constructors, each decorated with appropriate methods
as in `StmtLR`. The desugaring code is separate anyway. There would be
some duplication of typechecking code, not not a lot. But I think the
clarity would be worth it; code dealing with arrows would, well, deal with
arrows, and other code would not need to worry about the case that it was
actually (say) typechecking an arrow abstraction. Decoupling the two
would simplify both -- admittedly at the cost of a bit more code. But I
feel that the code-sharing we get just isn't paying its way.
If you felt able to look at this it would be fantastic. I'd be happy to
have a Skype chat about details, if that would help. Frankly I'm out of
my depth with the arrow syntax.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5333#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list