GHC issueshttps://gitlab.haskell.org/ghc/ghc/issues2019-04-02T23:54:34Zhttps://gitlab.haskell.org/ghc/ghc/issues/16501Record updates for existential fields do not work + confusing error2019-04-02T23:54:34ZIavor S. DiatchkiRecord updates for existential fields do not work + confusing errorIt would appear that updating a field with an existentially quantified type does not work, when using the record update notation. Here is an example:
```
{-# Language GADTs #-} -- Only uses Existentials
data T where
Str :: Show s => { field :: s } -> T
val1 :: T
val1 = Str { field = True }
{-
val2 :: T
val2 = val1 { field = 'a' }
• Record update for insufficiently polymorphic field: field :: s
• In the expression: val1 {field = 'a'}
In an equation for ‘val2’: val2 = val1 {field = 'a'}
-}
manualUpdate :: Show s => T -> s -> T
manualUpdate (Str _) s = Str s
val3 :: T
val3 = manualUpdate val1 'a'
```
Is there a reason why this shouldn't work? I would imagine that we'd like the record update to behave just like `manualUpdate` in the example.
Also, the error seems quite odd: how can a field be "insufficiently polymorphic"? After all, it is ok to update completely monomorphic fields.It would appear that updating a field with an existentially quantified type does not work, when using the record update notation. Here is an example:
```
{-# Language GADTs #-} -- Only uses Existentials
data T where
Str :: Show s => { field :: s } -> T
val1 :: T
val1 = Str { field = True }
{-
val2 :: T
val2 = val1 { field = 'a' }
• Record update for insufficiently polymorphic field: field :: s
• In the expression: val1 {field = 'a'}
In an equation for ‘val2’: val2 = val1 {field = 'a'}
-}
manualUpdate :: Show s => T -> s -> T
manualUpdate (Str _) s = Str s
val3 :: T
val3 = manualUpdate val1 'a'
```
Is there a reason why this shouldn't work? I would imagine that we'd like the record update to behave just like `manualUpdate` in the example.
Also, the error seems quite odd: how can a field be "insufficiently polymorphic"? After all, it is ok to update completely monomorphic fields.https://gitlab.haskell.org/ghc/ghc/issues/16693Order of declarations affects which programs are accepted (type families and ...2020-01-23T19:39:43ZIavor S. DiatchkiOrder of declarations affects which programs are accepted (type families and existentials)Consider the following example:
```haskell
{-# LANGUAGE ExistentialQuantification, TypeFamilies #-}
module Bug where
type family G n
type instance G a = F
data T = forall w. T (G w)
type family F where F = ()
-- type family G n
```
GHC rejects this program, when checking if `T` is ambiguous. However, if I move the declaration of `G` to the end of the file (the declaration that is commented out), then GHC accepts the program.
I would guess that, somehow, it matters in what order things are processed---if `G` is evaluated fully first, it can resolve to `()` and there is no ambiguity. However, if `G` is not evaluated, then there appears to be an ambiguity as `w` occurs under a type family.Consider the following example:
```haskell
{-# LANGUAGE ExistentialQuantification, TypeFamilies #-}
module Bug where
type family G n
type instance G a = F
data T = forall w. T (G w)
type family F where F = ()
-- type family G n
```
GHC rejects this program, when checking if `T` is ambiguous. However, if I move the declaration of `G` to the end of the file (the declaration that is commented out), then GHC accepts the program.
I would guess that, somehow, it matters in what order things are processed---if `G` is evaluated fully first, it can resolve to `()` and there is no ambiguity. However, if `G` is not evaluated, then there appears to be an ambiguity as `w` occurs under a type family.Vladislav ZavialovVladislav Zavialov