[GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module

[GHC]

#14963: ghci -fdefer-type-errors can't run IO action from another module
-------------------------------------+-------------------------------------
        Reporter:  elaforge          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.4.2
       Component:  GHCi              |              Version:  8.4.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 After a long discussion of design possibilities, Simon and I came to the
 following:

 1. The current design is broken, as described in this ticket.

 2. If we want to handle all rebindable syntax in a general fashion, we
 were unable to come up with anything simpler than the "impenetrable" code
 that exists. And, indeed, to fix the current flaw would likely require
 adding `HList`s or some such, making it even worse.

 3. Much of the current complication comes from the handling of `>>=`,
 which has an intricate type. Specifically, we need `(>>=) :: ty1 -> (ty2
 -> ty3) -> ty4`. However, it would also be quite cool if something like
 `(>>=) :: ty1 -> (forall a. ty2 -> ty3) -> ty4` were allowed. This
 effectively means that a `<-` operator in a `do` could bind an existential
 variable without using a pattern-match. And, if the user wrote `(>>=)`
 literally (without `do`), then this would indeed be possible. So it would
 be nice.

   The complication specifically stems from the fact that the code
 processing `BindStmt`s needs to know `ty2` and `ty3`, so we must decompose
 the type of `(>>=)`'s second argument. In order to do this, we need to
 skolemize any `forall`d variables, and skolemization requires an
 implication constraint, causing the bug in this ticket.

 4. Rebindable syntax that decomposes list constructors suffers a similar
 fate, but that's not nearly as painful as `(>>=)`.

 Though I'm still not fully convinced, we resolved to make the treatment of
 rebindable syntax simpler and less general. Specifically:

 a. Reduce `SyntaxOpType` to have two constructors: `SynAny ::
 SyntaxOpType` and `SynType :: ExpType -> SyntaxOpType`.

 b. Make new functions `tcBindOp`, `tcFromListOp`, and `tcFromListNOp` that
 handle the special cases for `(>>=)` and the list functions. These won't
 use general mechanisms, but just be a bit repetitive with `tcSyntaxOp`.

 c. The `SynRho` case of `tcSyntaxOp` will be dropped. Instead, clients of
 `tcSyntaxOp` that need rho-types will arrange to instantiate/skolemize the
 sigma-types that `tcSyntaxOp` provides as needed. This will duplicate
 code, but it means that `tcSyntaxOp` no longer needs to be written in CPS
 style. It will also allow this ticket to be resolved.

 d. This still won't handle cases like `fromListN :: (forall a. Int) -> [b]
 -> c`, where one parameter of a bit of rebindable syntax has a known type,
 but that known type might be redundantly quantified. Handling such a case
 would require CPSing again, and so we won't. This means that rebindable
 syntax will be a bit less expressive than the manual has heretofore
 promised. But the only lost cases are surely of the form above, where
 there is an unused quantified type variable. We can arrange for a suitable
 error message in these cases. This change will require a user manual
 update.

 e. When all this is done, the extra flexibility in the `SyntaxExpr` type
 -- with its argument wrappers and result wrapper -- won't be needed.
 Instead, `tcSyntaxOp` can return a plain old `HsExpr`, suitably wrapped.
 Accommodations will have to be made in `BindStmt` and the places where
 list operators might crop up to store extra `HsWrapper`s to be applied to
 arguments.

 f. A Note will be placed near `tcSyntaxOp` and the bind/list functions
 describing this design plan. If, in the future, we want more rebindable
 syntax, it might encourage us to re-adopt the more general -- but more
 complicated -- scheme currently in place.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14963#comment:11>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler