Refactor the implementation of arrow notation

[simonpj]

The implementation of arrow notation is not really satisfactory. See #1662 for some background.

To fix it properly we need to re-factor the way that arrows are typechecked. Ross and I discussed this. Our preliminary plan is this.

• Instead of re-using HsExpr for commands, make a new data type. (C.f. the comments in HsExpr line 540 or so.)
• That will allow the renamer to decorate the (now command-specific) tree with what variables are in scope where, and that in turn will greatly simplify the desugarer. (The desugarer is currently duplicating much of what the renamer does.)
• We'll need think about constraint gathering for "holes in the scope". cf #1662

[clanehin]

I believe that this is an example of the problem:

arrowAddInt :: (Arrow a) => a Integer (forall n. (Num n) => n -> n)
arrowAddInt = proc n -> returnA -< (+ fromInteger n)

    Cannot match a monotype with `forall n. (Num n) => n -> n'
      Expected type: a b (forall n. (Num n) => n -> n)
      Inferred type: a b b
    In the expression: proc n -> returnA -< (+ (fromInteger n))
    In the definition of `arrowAddInt':
        arrowAddInt = proc n -> returnA -< (+ (fromInteger n))

[morabbin]

Bump; still relevant?

[simonpj]

Actually refactoring has been done.