Rearrange the typechecking of arrows, especially arrow "forms"
The typechecking of arrow forms (in GHC 7.6) is known to be bogus, as described in Trac #5609, because it marches down tuple types that may not yet be fully worked out, depending on when constraint solving happens. Moreover, coercions are generated and simply discarded. The fact that it works at all is a miracle. This refactoring is based on a conversation with Ross, where we rearranged the typing of the argument stack, so that the arrows have the form a (env, (arg1, (arg2, ...(argn, ())))) res rather than a (arg1, (arg2, ...(argn, env))) res as it was before. This is vastly simpler to typecheck; just look at the beautiful, simple type checking of arrow forms now! We need a new HsCmdCast to capture the coercions generated from the argument stack. This leaves us in a better position to tackle the open arrow tickets * Trac #5777 still fails. (I was hoping this patch would cure it.) * Trac #5609 is too complicated for me to grok. Ross? * Trac #344 * Trac #5333
Showing
- compiler/deSugar/Coverage.lhs 3 additions, 0 deletionscompiler/deSugar/Coverage.lhs
- compiler/deSugar/DsArrows.lhs 275 additions, 211 deletionscompiler/deSugar/DsArrows.lhs
- compiler/hsSyn/HsExpr.lhs 10 additions, 3 deletionscompiler/hsSyn/HsExpr.lhs
- compiler/hsSyn/HsUtils.lhs 5 additions, 2 deletionscompiler/hsSyn/HsUtils.lhs
- compiler/parser/Parser.y.pp 2 additions, 2 deletionscompiler/parser/Parser.y.pp
- compiler/parser/RdrHsSyn.lhs 2 additions, 2 deletionscompiler/parser/RdrHsSyn.lhs
- compiler/rename/RnExpr.lhs 3 additions, 1 deletioncompiler/rename/RnExpr.lhs
- compiler/rename/RnTypes.lhs 1 addition, 1 deletioncompiler/rename/RnTypes.lhs
- compiler/typecheck/TcArrows.lhs 123 additions, 149 deletionscompiler/typecheck/TcArrows.lhs
- compiler/typecheck/TcHsSyn.lhs 5 additions, 1 deletioncompiler/typecheck/TcHsSyn.lhs
- docs/users_guide/glasgow_exts.xml 32 additions, 16 deletionsdocs/users_guide/glasgow_exts.xml
Loading
Please register or sign in to comment