Odtnhj

Consider the following code snippet:

import Data.Text (Text)
import qualified Data.Text as T
import qualified Data.Vector.Unboxed as UV
import qualified Data.Vector.Generic as V

bar :: Int -> UV.Vector Char -> (Text, Text)
bar i v = (t_pre, t_post)
 where
 f = T.pack . V.toList
 (t_pre, t_post) = ((x, y) -> (f x, f y)) $ V.splitAt i v

This compiles ok as you might expect. However, if you replace the function calls with view patterns, you get a type error.

-# LANGUAGE ViewPatterns #-

import Data.Text (Text)
import qualified Data.Text as T
import qualified Data.Vector.Unboxed as UV
import qualified Data.Vector.Generic as V

bar :: Int -> UV.Vector Char -> (Text, Text)
bar i v = (t_pre, t_post)
 where
 f = T.pack . V.toList
 (f -> t_pre, f -> t_post) = V.splitAt i v

This prints the following message (with -fprint-potential-instances):

 • Ambiguous type variable ‘v0’ arising from a use of ‘V.toList’
 prevents the constraint ‘(V.Vector v0 Char)’ from being solved.
 Relevant bindings include
 f :: v0 Char -> Text (bound at Weird.hs:11:5)
 Probable fix: use a type annotation to specify what ‘v0’ should be.
 These potential instances exist:
 instance V.Vector UV.Vector Char
 -- Defined in ‘Data.Vector.Unboxed.Base’
 ...plus one instance involving out-of-scope types
 instance primitive-0.6.3.0:Data.Primitive.Types.Prim a =>
 V.Vector Data.Vector.Primitive.Vector a
 -- Defined in ‘Data.Vector.Primitive’
 • In the second argument of ‘(.)’, namely ‘V.toList’
 In the expression: T.pack . V.toList
 In an equation for ‘f’: f = T.pack . V.toList
 |
11 | f = T.pack . V.toList
 | ^^^^^^^^

Weird.hs:13:6: error:
 Variable not in scope: f :: UV.Vector Char -> t
 |
13 | (f -> t_pre, f -> t_post) = V.splitAt i v
 | ^

Weird.hs:13:18: error:
 Variable not in scope: f :: UV.Vector Char -> t1
 |
13 | (f -> t_pre, f -> t_post) = V.splitAt i v
 | ^

My understanding is that both the ways of expressing things are entirely equivalent, because a view pattern is just function application without naming the bound variable. Am I misunderstanding view patterns? Is it the desugaring that is interacting with the type checker in an unexpected manner? If I inline the definition of f at both the call sites, the type error goes away.

I've tested this with GHCi 8.4.3.

Update: This is a compiler bug. See GHC Trac #14293 for more details.

You have a problem with f which is caused by the monomorphism restriction. If you eta expand f, give it a type signature, or turn on NoMonomorphismRestriction, then this error will go away.

But you're still left with these errors, which came as a surprise to me!

Weird.hs:13:6: error:
 Variable not in scope: f :: UV.Vector Char -> t
 |
13 | (f -> t_pre, f -> t_post) = V.splitAt i v
 | ^

Weird.hs:13:18: error:
 Variable not in scope: f :: UV.Vector Char -> t1
 |
13 | (f -> t_pre, f -> t_post) = V.splitAt i v
 | ^

I guess view patterns don't work if they are defined in the same scope. To see if view patterns needed to be top-level, I tried

bar :: Int -> UV.Vector Char -> (Text, Text)
bar i v = let (f -> t_pre, f -> t_post) = V.splitAt i v in (t_pre, t_post)
 where
 f = T.pack . V.toList

which worked fine. So I tried

f = T.pack . V.toList
(f -> t_pre, f -> t_post) = V.splitAt 0 UV.empty

Which fails with f not in scope.

Finally, if I put those patterns under a function call

f = T.pack . V.toList
g (f -> t_pre, f -> t_post) = V.splitAt 0 UV.empty

then it's fine again. So I guess the rule is that a "value" pattern binding can't use a view pattern which is defined in the same scope. I find that weird, it might even be a bug.

This is quite weird indeed. It might be a bug.

Modifying the original code as follows

where
f x = T.pack (V.toList x)
(f -> t_pre, f -> t_post) = V.splitAt i v

makes GHC ask for FlexibleContexts. After doing that, we get a very strange error:

 Variable not in scope: f :: UV.Vector Char -> t
 |
12 | (f -> t_pre, f -> t_post) = V.splitAt i v
 | ^
 Variable not in scope: f :: UV.Vector Char -> t1
 |
12 | (f -> t_pre, f -> t_post) = V.splitAt i v
 | ^

This seems like a bug to me. f should be in scope there.

Moving f to global scope:

 ...
 where
 (f -> t_pre, f -> t_post) = V.splitAt i v

f x = T.pack (V.toList x)

The code now works just fine. It even works if we revert the global f to the pointfree definition.

Using an explicit type annotation, as in

where
f :: UV.Vector Char -> Text
f x = T.pack (V.toList x)
(f -> t_pre, f -> t_post) = V.splitAt i v

produces a puzzling error message

• Variable not in scope: f :: UV.Vector Char -> t
• Perhaps you meant ‘f’ (line 12)

I can't understand what's really going on. In GHCi, both these work fine

> let f = id ; foo (f -> x) = x in foo ()
()
> let bar = foo () where f = id ; foo (f -> x) = x in bar
()

Hence, we can use a local f in view patterns. Still, when the type of f needs some more careful type inference (?), then it can not be used in view patterns. This looks like a bug. At the very least, the error message should be more clear.