[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