mistranslation of arrow notation

[ross]

(Split from #1333)

arrowrun004 has a core lint failure for all ways:

*** Core Lint Errors: in result of Desugar ***
<no location info>:
    In the expression: >>>_aEC @ () @ () @ GHC.Base.Int
    >>>_aEC is out of scope
*** Offending Program *** 
[...]
Main.expr :: Main.ExprParser () GHC.Base.Int
[]
Main.expr =
  >>>_aEC
    @ ()
    @ ()
    @ GHC.Base.Int
    (arr_aEB
[...]

[ross]

The source program

expr = proc () -> do
        x <- term -< ()
        expr' -< x

is translated by the type checker to (simplified a bit):

expr = proc
  (){(w) d 70} { arr{v aEB} [lid] = arr{v 01V} [gid]
                                        @ (<nt>BTParser{tc rdM} ESym{tc rdD})
                                        $dArrow{v aEE} [lid]
                 $dArrow{v aEE} [lid] = $f4{v rqS} [lid] @ ESym{tc rdD}
                 >>>{v aEC} [lid] = (>>>{v 01W} [gid]) 
                                        @ (<nt>BTParser{tc rdM} ESym{tc rdD}) 
                                        $dArrow{v aEF} [lid]
                 $dArrow{v aEF} [lid] = $dArrow{v aEE} [lid]
                 first{v aED} [lid] = first{v 01X} [gid] 
                                        @ (<nt>BTParser{tc rdM} ESym{tc rdD}) 
                                        $dArrow{v aEG} [lid]
                 $dArrow{v aEG} [lid] = $dArrow{v aEE} [lid] }
  ->
  do ((x{v aeB} [lid] :: Int{(w) tc 3J})) <-
                term{v rdq} [lid] -< (){(w) v 71} [gid]
     expr'{v rdo} [lid] -< x{v aeB} [lid]

These bindings ought not to be attached to the pattern of proc, because the scope of pat in proc pat -> cmd is not the whole of cmd but only the subexpressions that are fed into arrows. The bindings should be placed outside the proc expression, so that they scope over the whole thing.

[ross]

Simpler example (from g9ks157k@…):

arrow :: (Arrow a) => a () ()
arrow = proc () -> do returnA -< ()

[g9ks157k@…]

Note that the problem doesn’t occur when using GHCi.

[simonpj]

After a conversation with Ross I understand what is going on. Here's the new comment in TcPat

Note [Arrows and patterns]
~~~~~~~~~~~~~~~~~~~~~~~~~~
(Oct 07) Arrow noation has the odd property that it involves
 "holes in the scope". For example:
  expr :: Arrow a => a () Int
  expr = proc (y,z) -> do
          x <- term -< y
          expr' -< x

Here the 'proc (y,z)' binding scopes over the arrow tails but not the
arrow body (e.g 'term').  As things stand (bogusly) all the
constraints from the proc body are gathered together, so constraints
from 'term' will be seen by the tcPat for (y,z).  But we must *not*
bind constraints from 'term' here, becuase the desugarer will not make
these bindings scope over 'term'.

The Right Thing is not to confuse these constraints together. But for
now the Easy Thing is to ensure that we do not have existential or
GADT constraints in a 'proc', and to short-cut the constraint
simplification for such vanilla patterns so that it binds no
constraints. Hence the 'fast path' in tcConPat; but it's also a good
plan for ordinary vanilla patterns to bypass the constraint
simplification step.

So this bug is not really fixed properly; but it's significantly improved.

See Task #1777.

Ian please merge

Tue Oct 16 13:47:10 BST 2007  simonpj@microsoft.com
  * Fix #1662: do not simplify constraints for vanilla pattern matches

[igloo]

Merged

[guest]

As I understand the above TcPat comment, the compiler should not accept proc expressions with existential constraints. Therefore, I would expect GHC 6.8.1 to fail on the following code:

{-# LANGUAGE Arrows, ExistentialQuantification #-}
module ANewPanicWithArrows where

    import Control.Arrow

    data T = forall a. T a

    panic :: (Arrow arrow) => arrow T T
    panic = proc (T x) -> do returnA -< T x

However, as the code suggests, GHC doesn’t fail but panics again:

ghc-6.8.1: panic! (the 'impossible' happened)
  (GHC version 6.8.1 for i386-unknown-linux):
        initC: srt_lbl

If I load the module into GHCi, GHCi doesn’t complain, but it panics with nameModule arr{v apv} (instead of initC: srt_lbl) when I start to use the panic arrow.

[simonpj]

Quite right! I forgot to add the test.

New patch:

Wed Nov 14 11:29:30 GMT 2007  simonpj@microsoft.com
  * FIX Trac 1662: actually check for existentials in proc patterns

Ian pls merge

New test is arrowfail004

Simon

[igloo]

Merged