Opened 8 years ago

Closed 7 years ago

Last modified 2 years ago

#5609 closed bug (fixed)

Type checking arrow notation in the presence of deferred constraints

Reported by: dreixel Owned by: ross
Priority: low Milestone: 7.6.2
Component: Compiler (Type checker) Version: 7.3
Keywords: Arrows Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


In TcArrows, the following code

    tc_cmd w_tv (cmd, i, b, tup_ty, s)
      = do { tup_ty' <- zonkTcType tup_ty
	   ; let (corner_ty, arg_tys) = unscramble tup_ty'

		-- Check that it has the right shape:
		-- 	((w,s1) .. sn)
		-- where the si do not mention w
	   ; checkTc (corner_ty `eqType` mkTyVarTy w_tv && 
		      not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))
		     (badFormFun i tup_ty')

	   ; tcCmdTop (env { cmd_arr = b }) cmd arg_tys s }

is wrong. In particular, the check elemVarSet w_tv (tyVarsOfTypes arg_tys) does not make sense in the presence of deferred constraints.

There is no testcase for this at the moment, but in the ghc-kinds branch both T5283 and arrowform1 fail because of this. The temporary fix was:

           ; _bogus <- unifyType corner_ty (mkTyVarTy w_tv)
	   ; checkTc (not (w_tv `elemVarSet` tyVarsOfTypes arg_tys))
		     (badFormFun i tup_ty')

This solves only T5283 and arrowform1; other problems might arise in the future, so this should be fixed properly.

Change History (7)

comment:1 Changed 8 years ago by simonpj

This ticket is closely related to #5267; it's the same bit of code.


comment:2 Changed 8 years ago by igloo

Milestone: 7.4.1
Owner: set to ross

comment:3 Changed 8 years ago by igloo

Priority: normallow

comment:4 Changed 7 years ago by igloo


comment:5 Changed 7 years ago by simonpj@…

commit c3ad38d7dc39ef583ddfb586413baa2e57ca3ee8

Author: Simon Peyton Jones <>
Date:   Mon Mar 4 09:40:56 2013 +0000

    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

 compiler/deSugar/Coverage.lhs     |    3 +
 compiler/deSugar/DsArrows.lhs     |  486 +++++++++++++++++++++----------------
 compiler/hsSyn/HsExpr.lhs         |   13 +-
 compiler/hsSyn/HsUtils.lhs        |    7 +-
 compiler/parser/Parser.y.pp       |    4 +-
 compiler/parser/RdrHsSyn.lhs      |    4 +-
 compiler/rename/RnExpr.lhs        |    4 +-
 compiler/rename/RnTypes.lhs       |    2 +-
 compiler/typecheck/TcArrows.lhs   |  272 ++++++++++-----------
 compiler/typecheck/TcHsSyn.lhs    |    6 +-
 docs/users_guide/glasgow_exts.xml |   48 +++--
 11 files changed, 461 insertions(+), 388 deletions(-)

comment:6 Changed 7 years ago by simonpj

difficulty: Unknown
Resolution: fixed
Status: newclosed

Right this is fixed. We don't really have a test-case that exercises the snazzy capabilities, but it all looks right now, and existing regression tests pass.

comment:7 Changed 2 years ago by simonpj

Keywords: Arrows added
Note: See TracTickets for help on using tickets.