Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kind information is lost on incremental compilation #383

Open
matil019 opened this issue Oct 21, 2019 · 0 comments
Open

Kind information is lost on incremental compilation #383

matil019 opened this issue Oct 21, 2019 · 0 comments
Assignees
Labels

Comments

@matil019
Copy link
Member

The kinds of type variables in type aliases are correctly infered on full compilation but not on incremental one.

For example:

module foo.Lens where

type Lens s t a b = forall f. Functor f => (a -> f b) -> s -> f t 
module foo.Main where

import foo.Lens (Lens)

data User = User { _name :: String }
  where
  user :: Lens User User String String
  user f this = (\name' -> this.{_name=name'}) <$> f this._name
derive Show User

main :: IO ()
main = do
    let me = User "foo"
    -- prints:
    -- User "Mr. foo"
    println =<< User.user (pure . ("Mr. " ++)) me

If both of the two modules are compiled at once, it works. However, if foo.Lens is compiled, and then foo.Main is compiled in another run, a kind error occurs:

$  java -jar fregec.jar -make foo.Lens
$  java -jar fregec.jar -make foo.Main
...
E ./foo/Main.fr:1: kind error, type variable `f` has kind *, expected was ? -> *
E ./foo/Main.fr:8: Kind error in unification of 
    t7684 :: * -> *  with
    f :: *                                 
E ./foo/Main.fr:8: type error in expression                                                        
    f this._name     
    type is : f String
    expected: t1 String                         
...

(Presence of -make is irrelevant but put anyway to illustrate a common use case.)

As a workaround, the type annotation can be expanded by hand:

user :: Functor f => (String -> f String) -> User -> f User
@Ingo60 Ingo60 self-assigned this Oct 22, 2019
@Ingo60 Ingo60 added the bug label Oct 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants