From wolfgangit at jeltsch.info Wed Jul 5 00:21:04 2017
From: wolfgangit at jeltsch.info (Wolfgang Jeltsch)
Date: Wed, 05 Jul 2017 03:21:04 +0300
Subject: Trouble with injective type families
MessageID: <1499214064.2497.44.camel@jeltsch.info>
Hi!
Injective type families as supported by GHC 8.0.1 do not behave like I
would expect them to behave from my intuitive understanding.
Let us consider the following example:
> {# LANGUAGE RankNTypes, TypeFamilyDependencies #}
>
> class C a where
>
> type T a = b  b > a
>
> instance C Bool where
>
> type T Bool = Int
>
> type X b = forall a . T a ~ b => a
>
> x :: X Int
> x = False
I would expect this code to be accepted. However, I get the following
error message:
> A.hs:14:5: error:
> • Could not deduce: a ~ Bool
> from the context: T a ~ Int
> bound by the type signature for:
> x :: T a ~ Int => a
> at A.hs:13:110
> ‘a’ is a rigid type variable bound by
> the type signature for:
> x :: forall a. T a ~ Int => a
> at A.hs:11:19
> • In the expression: False
> In an equation for ‘x’: x = False
> • Relevant bindings include x :: a (bound at A.hs:14:1)
This is strange, since injectivity should exactly make it possible to
deduce a ~ Bool from T a ~ Int.
Another example is this:
> {# LANGUAGE GADTs, TypeFamilyDependencies #}
>
> class C a where
>
> type T a = b  b > a
>
> instance C Bool where
>
> type T Bool = Int
>
> data G b where
>
> G :: Eq a => a > G (T a)
>
> instance Eq (G b) where
>
> G a1 == G a2 = a1 == a2a
I would also expect this code to be accepted. However, I get the
following error message:
> B.hs:17:26: error:
> • Could not deduce: a1 ~ a
> from the context: (b ~ T a, Eq a)
> bound by a pattern with constructor:
> G :: forall a. Eq a => a > G (T a),
> in an equation for ‘==’
> at B.hs:17:58
> or from: (b ~ T a1, Eq a1)
> bound by a pattern with constructor:
> G :: forall a. Eq a => a > G (T a),
> in an equation for ‘==’
> at B.hs:17:1316
> ‘a1’ is a rigid type variable bound by
> a pattern with constructor: G :: forall a. Eq a => a > G (T a),
> in an equation for ‘==’
> at B.hs:17:13
> ‘a’ is a rigid type variable bound by
> a pattern with constructor: G :: forall a. Eq a => a > G (T a),
> in an equation for ‘==’
> at B.hs:17:5
> • In the second argument of ‘(==)’, namely ‘a2’
> In the expression: a1 == a2
> In an equation for ‘==’: (G a1) == (G a2) = a1 == a2
> • Relevant bindings include
> a2 :: a1 (bound at B.hs:17:15)
> a1 :: a (bound at B.hs:17:7)
If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1,
because of injectivity. Unfortunately, GHC does not join the two
contexts (b ~ T a, Eq a) and (b ~ T a1, Eq a1).
Are these behaviors really intended, or are these bugs showing up?
All the best,
Wolfgang
From simonpj at microsoft.com Wed Jul 5 06:45:52 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 5 Jul 2017 06:45:52 +0000
Subject: Trouble with injective type families
InReplyTo: <1499214064.2497.44.camel@jeltsch.info>
References: <1499214064.2497.44.camel@jeltsch.info>
MessageID:
Functional dependencies and typefamily dependencies only induce extra "improvement" constraints, not evidence. For example
class C a b  a > b where foo :: a > b
instance C Bool Int where ...
f :: C Bool b => b > Int
f x = x  Rejected
Does the fundep on 'b' allow us to deduce (b ~ Int), GADTlike, in the body of 'f', and hence accept the definition. No, it does not. Think of the translation into System F. We get
f = /\b \(d :: C Bool b). \(x::b). x > ???
What evidence can I used to cast 'x' by to get it from type 'b' to Int?
Rather, fundeps resolve ambiguity. Consider
g x = foo True + x
The call to 'foo True' gives rise to a "wanted" constraint (C Bool beta), where beta is a fresh unification variable. Then by the fundep we get an "improvement" constraint (also "wanted") (beta ~ Int). So we can infer g :: Int > Int.
In your example we have
x :: forall a b. (T Int ~ b) => a
x = False
Think of the System F translation:
x = /\a b. \(d :: T Int ~ b). False > ??
Again, what evidence can we use to cast False to 'a'.
In short, fundeps and type family dependencies only add extra unification constraints, which may help to resolve ambiguous types. They don’t provide evidence. That's not to say that they couldn't. But you'd need to extend System FC, GHC's core language, to do so.
Simon
 Original Message
 From: Glasgowhaskellusers [mailto:glasgowhaskellusers
 bounces at haskell.org] On Behalf Of Wolfgang Jeltsch
 Sent: 05 July 2017 01:21
 To: glasgowhaskellusers at haskell.org
 Subject: Trouble with injective type families

 Hi!

 Injective type families as supported by GHC 8.0.1 do not behave like I
 would expect them to behave from my intuitive understanding.

 Let us consider the following example:

 > {# LANGUAGE RankNTypes, TypeFamilyDependencies #}
 >
 > class C a where
 >
 > type T a = b  b > a
 >
 > instance C Bool where
 >
 > type T Bool = Int
 >
 > type X b = forall a . T a ~ b => a
 >
 > x :: X Int
 > x = False

 I would expect this code to be accepted. However, I get the following
 error message:

 > A.hs:14:5: error:
 > • Could not deduce: a ~ Bool
 > from the context: T a ~ Int
 > bound by the type signature for:
 > x :: T a ~ Int => a
 > at A.hs:13:110
 > ‘a’ is a rigid type variable bound by
 > the type signature for:
 > x :: forall a. T a ~ Int => a
 > at A.hs:11:19
 > • In the expression: False
 > In an equation for ‘x’: x = False
 > • Relevant bindings include x :: a (bound at A.hs:14:1)

 This is strange, since injectivity should exactly make it possible to
 deduce a ~ Bool from T a ~ Int.

 Another example is this:

 > {# LANGUAGE GADTs, TypeFamilyDependencies #}
 >
 > class C a where
 >
 > type T a = b  b > a
 >
 > instance C Bool where
 >
 > type T Bool = Int
 >
 > data G b where
 >
 > G :: Eq a => a > G (T a)
 >
 > instance Eq (G b) where
 >
 > G a1 == G a2 = a1 == a2a

 I would also expect this code to be accepted. However, I get the
 following error message:

 > B.hs:17:26: error:
 > • Could not deduce: a1 ~ a
 > from the context: (b ~ T a, Eq a)
 > bound by a pattern with constructor:
 > G :: forall a. Eq a => a > G (T a),
 > in an equation for ‘==’
 > at B.hs:17:58
 > or from: (b ~ T a1, Eq a1)
 > bound by a pattern with constructor:
 > G :: forall a. Eq a => a > G (T a),
 > in an equation for ‘==’
 > at B.hs:17:1316
 > ‘a1’ is a rigid type variable bound by
 > a pattern with constructor: G :: forall a. Eq a => a > G (T
 > a),
 > in an equation for ‘==’
 > at B.hs:17:13
 > ‘a’ is a rigid type variable bound by
 > a pattern with constructor: G :: forall a. Eq a => a > G (T
 > a),
 > in an equation for ‘==’
 > at B.hs:17:5
 > • In the second argument of ‘(==)’, namely ‘a2’
 > In the expression: a1 == a2
 > In an equation for ‘==’: (G a1) == (G a2) = a1 == a2
 > • Relevant bindings include
 > a2 :: a1 (bound at B.hs:17:15)
 > a1 :: a (bound at B.hs:17:7)

 If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1, because
 of injectivity. Unfortunately, GHC does not join the two contexts (b ~ T
 a, Eq a) and (b ~ T a1, Eq a1).

 Are these behaviors really intended, or are these bugs showing up?

 All the best,
 Wolfgang
 _______________________________________________
 Glasgowhaskellusers mailing list
 Glasgowhaskellusers at haskell.org
 https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
 ell.org%2Fcgibin%2Fmailman%2Flistinfo%2Fglasgowhaskell
 users&data=02%7C01%7Csimonpj%40microsoft.com%7Cc333fbaff2f4406c337e08d4c3
 3bd1bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636348109082017989&sd
 ata=q%2B8ZSqYfNjC7x6%2Bm9vpsgCmCDo%2FIItppqB5Nwzf6Qj0%3D&reserved=0
From wolfgangit at jeltsch.info Wed Jul 5 13:37:23 2017
From: wolfgangit at jeltsch.info (Wolfgang Jeltsch)
Date: Wed, 05 Jul 2017 16:37:23 +0300
Subject: Trouble with injective type families
InReplyTo:
References: <1499214064.2497.44.camel@jeltsch.info>
MessageID: <1499261843.2497.48.camel@jeltsch.info>
Dear Simon,
thank you very much for this elaborate explanation.
I stumbled on this issue when using functional dependencies years ago.
The solution at that time was to use type families.
I did not know that injectivity is handled analogously to functional
dependencies. Given that it is, the syntax for injectivity makes a lot
more sense.
All the best,
Wolfgang
Am Mittwoch, den 05.07.2017, 06:45 +0000 schrieb Simon Peyton Jones:
> Functional dependencies and typefamily dependencies only induce extra
> "improvement" constraints, not evidence. For example
>
> class C a b  a > b where foo :: a > b
> instance C Bool Int where ...
>
> f :: C Bool b => b > Int
> f x = x  Rejected
>
> Does the fundep on 'b' allow us to deduce (b ~ Int), GADTlike, in the
> body of 'f', and hence accept the definition. No, it does not. Think
> of the translation into System F. We get
>
> f = /\b \(d :: C Bool b). \(x::b). x > ???
>
> What evidence can I used to cast 'x' by to get it from type 'b' to
> Int?
>
> Rather, fundeps resolve ambiguity. Consider
>
> g x = foo True + x
>
> The call to 'foo True' gives rise to a "wanted" constraint (C Bool
> beta), where beta is a fresh unification variable. Then by the fundep
> we get an "improvement" constraint (also "wanted") (beta ~ Int). So we
> can infer g :: Int > Int.
>
>
> In your example we have
>
> x :: forall a b. (T Int ~ b) => a
> x = False
>
> Think of the System F translation:
>
> x = /\a b. \(d :: T Int ~ b). False > ??
>
> Again, what evidence can we use to cast False to 'a'.
>
>
> In short, fundeps and type family dependencies only add extra
> unification constraints, which may help to resolve ambiguous
> types. They don’t provide evidence. That's not to say that they
> couldn't. But you'd need to extend System FC, GHC's core language, to
> do so.
>
> Simon
>
>
> >
> > Original Message
> > From: Glasgowhaskellusers [mailto:glasgowhaskellusers
> > bounces at haskell.org] On Behalf Of Wolfgang Jeltsch
> > Sent: 05 July 2017 01:21
> > To: glasgowhaskellusers at haskell.org
> > Subject: Trouble with injective type families
> >
> > Hi!
> >
> > Injective type families as supported by GHC 8.0.1 do not behave like
> > I
> > would expect them to behave from my intuitive understanding.
> >
> > Let us consider the following example:
> >
> > >
> > > {# LANGUAGE RankNTypes, TypeFamilyDependencies #}
> > >
> > > class C a where
> > >
> > > type T a = b  b > a
> > >
> > > instance C Bool where
> > >
> > > type T Bool = Int
> > >
> > > type X b = forall a . T a ~ b => a
> > >
> > > x :: X Int
> > > x = False
> > I would expect this code to be accepted. However, I get the
> > following
> > error message:
> >
> > >
> > > A.hs:14:5: error:
> > > • Could not deduce: a ~ Bool
> > > from the context: T a ~ Int
> > > bound by the type signature for:
> > > x :: T a ~ Int => a
> > > at A.hs:13:110
> > > ‘a’ is a rigid type variable bound by
> > > the type signature for:
> > > x :: forall a. T a ~ Int => a
> > > at A.hs:11:19
> > > • In the expression: False
> > > In an equation for ‘x’: x = False
> > > • Relevant bindings include x :: a (bound at A.hs:14:1)
> > This is strange, since injectivity should exactly make it possible
> > to
> > deduce a ~ Bool from T a ~ Int.
> >
> > Another example is this:
> >
> > >
> > > {# LANGUAGE GADTs, TypeFamilyDependencies #}
> > >
> > > class C a where
> > >
> > > type T a = b  b > a
> > >
> > > instance C Bool where
> > >
> > > type T Bool = Int
> > >
> > > data G b where
> > >
> > > G :: Eq a => a > G (T a)
> > >
> > > instance Eq (G b) where
> > >
> > > G a1 == G a2 = a1 == a2a
> > I would also expect this code to be accepted. However, I get the
> > following error message:
> >
> > >
> > > B.hs:17:26: error:
> > > • Could not deduce: a1 ~ a
> > > from the context: (b ~ T a, Eq a)
> > > bound by a pattern with constructor:
> > > G :: forall a. Eq a => a > G (T a),
> > > in an equation for ‘==’
> > > at B.hs:17:58
> > > or from: (b ~ T a1, Eq a1)
> > > bound by a pattern with constructor:
> > > G :: forall a. Eq a => a > G (T a),
> > > in an equation for ‘==’
> > > at B.hs:17:1316
> > > ‘a1’ is a rigid type variable bound by
> > > a pattern with constructor: G :: forall a. Eq a => a > G
> > > (T
> > > a),
> > > in an equation for ‘==’
> > > at B.hs:17:13
> > > ‘a’ is a rigid type variable bound by
> > > a pattern with constructor: G :: forall a. Eq a => a > G
> > > (T
> > > a),
> > > in an equation for ‘==’
> > > at B.hs:17:5
> > > • In the second argument of ‘(==)’, namely ‘a2’
> > > In the expression: a1 == a2
> > > In an equation for ‘==’: (G a1) == (G a2) = a1 == a2
> > > • Relevant bindings include
> > > a2 :: a1 (bound at B.hs:17:15)
> > > a1 :: a (bound at B.hs:17:7)
> > If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1,
> > because
> > of injectivity. Unfortunately, GHC does not join the two contexts (b
> > ~ T
> > a, Eq a) and (b ~ T a1, Eq a1).
> >
> > Are these behaviors really intended, or are these bugs showing up?
> >
> > All the best,
> > Wolfgang
> > _______________________________________________
> > Glasgowhaskellusers mailing list
> > Glasgowhaskellusers at haskell.org
> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
> > .hask
> > ell.org%2Fcgibin%2Fmailman%2Flistinfo%2Fglasgowhaskell
> > users&data=02%7C01%7Csimonpj%40microsoft.com%7Cc333fbaff2f4406c337e0
> > 8d4c3
> > 3bd1bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363481090820179
> > 89&sd
> > ata=q%2B8ZSqYfNjC7x6%2Bm9vpsgCmCDo%2FIItppqB5Nwzf6Qj0%3D&reserved=0
From rae at cs.brynmawr.edu Wed Jul 5 14:16:10 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 5 Jul 2017 10:16:10 0400
Subject: Trouble with injective type families
InReplyTo: <1499261843.2497.48.camel@jeltsch.info>
References: <1499214064.2497.44.camel@jeltsch.info>
<1499261843.2497.48.camel@jeltsch.info>
MessageID: <45524D9C2026408DB88E6C3CA86C69A4@cs.brynmawr.edu>
I'd like to add that the reason we never extended System FC with support for injectivity is that the proof of soundness of doing so has remained elusive. A similar unsoundness in type improvement may cause unpredictable behavior in type inference, but it can't ever launch the rockets. So we keep it in type inference but out of FC.
Richard
> On Jul 5, 2017, at 9:37 AM, Wolfgang Jeltsch wrote:
>
> Dear Simon,
>
> thank you very much for this elaborate explanation.
>
> I stumbled on this issue when using functional dependencies years ago.
> The solution at that time was to use type families.
>
> I did not know that injectivity is handled analogously to functional
> dependencies. Given that it is, the syntax for injectivity makes a lot
> more sense.
>
> All the best,
> Wolfgang
>
> Am Mittwoch, den 05.07.2017, 06:45 +0000 schrieb Simon Peyton Jones:
>> Functional dependencies and typefamily dependencies only induce extra
>> "improvement" constraints, not evidence. For example
>>
>> class C a b  a > b where foo :: a > b
>> instance C Bool Int where ...
>>
>> f :: C Bool b => b > Int
>> f x = x  Rejected
>>
>> Does the fundep on 'b' allow us to deduce (b ~ Int), GADTlike, in the
>> body of 'f', and hence accept the definition. No, it does not. Think
>> of the translation into System F. We get
>>
>> f = /\b \(d :: C Bool b). \(x::b). x > ???
>>
>> What evidence can I used to cast 'x' by to get it from type 'b' to
>> Int?
>>
>> Rather, fundeps resolve ambiguity. Consider
>>
>> g x = foo True + x
>>
>> The call to 'foo True' gives rise to a "wanted" constraint (C Bool
>> beta), where beta is a fresh unification variable. Then by the fundep
>> we get an "improvement" constraint (also "wanted") (beta ~ Int). So we
>> can infer g :: Int > Int.
>>
>>
>> In your example we have
>>
>> x :: forall a b. (T Int ~ b) => a
>> x = False
>>
>> Think of the System F translation:
>>
>> x = /\a b. \(d :: T Int ~ b). False > ??
>>
>> Again, what evidence can we use to cast False to 'a'.
>>
>>
>> In short, fundeps and type family dependencies only add extra
>> unification constraints, which may help to resolve ambiguous
>> types. They don’t provide evidence. That's not to say that they
>> couldn't. But you'd need to extend System FC, GHC's core language, to
>> do so.
>>
>> Simon
>>
>>
>>>
>>> Original Message
>>> From: Glasgowhaskellusers [mailto:glasgowhaskellusers
>>> bounces at haskell.org] On Behalf Of Wolfgang Jeltsch
>>> Sent: 05 July 2017 01:21
>>> To: glasgowhaskellusers at haskell.org
>>> Subject: Trouble with injective type families
>>>
>>> Hi!
>>>
>>> Injective type families as supported by GHC 8.0.1 do not behave like
>>> I
>>> would expect them to behave from my intuitive understanding.
>>>
>>> Let us consider the following example:
>>>
>>>>
>>>> {# LANGUAGE RankNTypes, TypeFamilyDependencies #}
>>>>
>>>> class C a where
>>>>
>>>> type T a = b  b > a
>>>>
>>>> instance C Bool where
>>>>
>>>> type T Bool = Int
>>>>
>>>> type X b = forall a . T a ~ b => a
>>>>
>>>> x :: X Int
>>>> x = False
>>> I would expect this code to be accepted. However, I get the
>>> following
>>> error message:
>>>
>>>>
>>>> A.hs:14:5: error:
>>>> • Could not deduce: a ~ Bool
>>>> from the context: T a ~ Int
>>>> bound by the type signature for:
>>>> x :: T a ~ Int => a
>>>> at A.hs:13:110
>>>> ‘a’ is a rigid type variable bound by
>>>> the type signature for:
>>>> x :: forall a. T a ~ Int => a
>>>> at A.hs:11:19
>>>> • In the expression: False
>>>> In an equation for ‘x’: x = False
>>>> • Relevant bindings include x :: a (bound at A.hs:14:1)
>>> This is strange, since injectivity should exactly make it possible
>>> to
>>> deduce a ~ Bool from T a ~ Int.
>>>
>>> Another example is this:
>>>
>>>>
>>>> {# LANGUAGE GADTs, TypeFamilyDependencies #}
>>>>
>>>> class C a where
>>>>
>>>> type T a = b  b > a
>>>>
>>>> instance C Bool where
>>>>
>>>> type T Bool = Int
>>>>
>>>> data G b where
>>>>
>>>> G :: Eq a => a > G (T a)
>>>>
>>>> instance Eq (G b) where
>>>>
>>>> G a1 == G a2 = a1 == a2a
>>> I would also expect this code to be accepted. However, I get the
>>> following error message:
>>>
>>>>
>>>> B.hs:17:26: error:
>>>> • Could not deduce: a1 ~ a
>>>> from the context: (b ~ T a, Eq a)
>>>> bound by a pattern with constructor:
>>>> G :: forall a. Eq a => a > G (T a),
>>>> in an equation for ‘==’
>>>> at B.hs:17:58
>>>> or from: (b ~ T a1, Eq a1)
>>>> bound by a pattern with constructor:
>>>> G :: forall a. Eq a => a > G (T a),
>>>> in an equation for ‘==’
>>>> at B.hs:17:1316
>>>> ‘a1’ is a rigid type variable bound by
>>>> a pattern with constructor: G :: forall a. Eq a => a > G
>>>> (T
>>>> a),
>>>> in an equation for ‘==’
>>>> at B.hs:17:13
>>>> ‘a’ is a rigid type variable bound by
>>>> a pattern with constructor: G :: forall a. Eq a => a > G
>>>> (T
>>>> a),
>>>> in an equation for ‘==’
>>>> at B.hs:17:5
>>>> • In the second argument of ‘(==)’, namely ‘a2’
>>>> In the expression: a1 == a2
>>>> In an equation for ‘==’: (G a1) == (G a2) = a1 == a2
>>>> • Relevant bindings include
>>>> a2 :: a1 (bound at B.hs:17:15)
>>>> a1 :: a (bound at B.hs:17:7)
>>> If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1,
>>> because
>>> of injectivity. Unfortunately, GHC does not join the two contexts (b
>>> ~ T
>>> a, Eq a) and (b ~ T a1, Eq a1).
>>>
>>> Are these behaviors really intended, or are these bugs showing up?
>>>
>>> All the best,
>>> Wolfgang
>>> _______________________________________________
>>> Glasgowhaskellusers mailing list
>>> Glasgowhaskellusers at haskell.org
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail
>>> .hask
>>> ell.org%2Fcgibin%2Fmailman%2Flistinfo%2Fglasgowhaskell
>>> users&data=02%7C01%7Csimonpj%40microsoft.com%7Cc333fbaff2f4406c337e0
>>> 8d4c3
>>> 3bd1bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6363481090820179
>>> 89&sd
>>> ata=q%2B8ZSqYfNjC7x6%2Bm9vpsgCmCDo%2FIItppqB5Nwzf6Qj0%3D&reserved=0
> _______________________________________________
> Glasgowhaskellusers mailing list
> Glasgowhaskellusers at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/glasgowhaskellusers
From wolfgangit at jeltsch.info Wed Jul 5 21:23:22 2017
From: wolfgangit at jeltsch.info (Wolfgang Jeltsch)
Date: Thu, 06 Jul 2017 00:23:22 +0300
Subject: Heterogeneous equality
MessageID: <1499289802.2497.91.camel@jeltsch.info>
Hi!
The base package contains the module Data.Type.Equality, which contains
the type (:~:) for homogeneous equality. I was a bit surprised that
there is no type for heterogeneous equality there. Is there such a type
somewhere else in the standard library?
I tried to define a type for heterogeneous equality myself as follows:
> {# LANGUAGE GADTs, PolyKinds, TypeOperators #}
>
> data a :~~: b where
>
> HRefl :: a :~~: a
To my surprise, the kind of (:~~:) defined this way is k > k > *, not
k > l > *. Why is this? Apparently, the latter, more general, kind is
possible, since we can define (:~~:) :: k > l > * as follows:
> {# LANGUAGE GADTs, PolyKinds, TypeOperators #}
>
> data (a :: k) :~~: (b :: l) where
>
> HRefl :: a :~~: a
All the best,
Wolfgang
From anthony_clayden at clear.net.nz Fri Jul 7 02:11:31 2017
From: anthony_clayden at clear.net.nz (Anthony Clayden)
Date: Fri, 07 Jul 2017 14:11:31 +1200
Subject: Trouble with injective type families
MessageID: <595eedd3.209.53a3.32275@clear.net.nz>
> On Wed Jul 5 14:16:10 UTC 2017, Richard Eisenberg wrote:
> I'd like to add that the reason we never extended System
FC
> with support for injectivity is that the proof of
soundness
> of doing so has remained elusive.
Thank you Richard, Simon.
IIRC the original FDs through CHRs paper did think it sound
to allow given `C a b1` and `C a b2` conclude `b1 ~ b2`
under a FunDep `a > b`.
(I think that was also the case in Mark Jones'
original paper on FunDeps.)
(See Iavor's comments on Trac #10675, for example.)
I know GHC's current FunDep inference is lax,
because there's good reasons to want 'wiggle room'
with FunDep (in)consistency.
I'm suggesting we could tighten that consistency check;
then we might make make FD inference stronger(?)
https://github.com/ghcproposals/ghcproposals/pull/56#issuecomment312974557
AntC
>> Am Mittwoch, den 05.07.2017, 06:45 +0000 schrieb Simon
Peyton Jones:
>> Functional dependencies and typefamily dependencies only
induce extra
>> "improvement" constraints, not evidence. For example
>>
>> class C a b  a > b where foo :: a > b
>> instance C Bool Int where ...
>>
>> f :: C Bool b => b > Int
>> f x = x  Rejected
>>
>> Does the fundep on 'b' allow us to deduce (b ~ Int),
GADTlike, in the
>> body of 'f', and hence accept the definition. No, it
does not. Think
>> of the translation into System F. We get
>>
>> f = /\b \(d :: C Bool b). \(x::b). x > ???
>>
>> What evidence can I used to cast 'x' by to get it
>> from type 'b' to Int?
>>
>> Rather, fundeps resolve ambiguity. Consider
>>
>> g x = foo True + x
>>
>> The call to 'foo True' gives rise to a "wanted"
constraint (C Bool
>> beta), where beta is a fresh unification variable. Then
by the fundep
>> we get an "improvement" constraint (also "wanted") (beta
~ Int). So we
>> can infer g :: Int > Int.
>>
>>
>> In your example we have
>>
>> x :: forall a b. (T Int ~ b) => a
>> x = False
>>
>> Think of the System F translation:
>>
>> x = /\a b. \(d :: T Int ~ b). False > ??
>>
>> Again, what evidence can we use to cast False to 'a'.
>>
>>
>> In short, fundeps and type family dependencies only add
extra
>> unification constraints, which may help to resolve
ambiguous
>> types. They dont provide evidence. That's not to say
that they
>> couldn't. But you'd need to extend System FC, GHC's core
language, to
>> do so.
>>
>> Simon
>>
>>
>>>
>>> Original Message
>>> From: Glasgowhaskellusers
[mailto:glasgowhaskellusers
>>> bounces at haskell.org] On Behalf Of Wolfgang Jeltsch
>>> Sent: 05 July 2017 01:21
>>> To: glasgowhaskellusers at haskell.org
>>> Subject: Trouble with injective type families
>>>
>>> Hi!
>>>
>>> Injective type families as supported by GHC 8.0.1 do not
behave like
>>> I
>>> would expect them to behave from my intuitive
understanding.
>>>
>>> Let us consider the following example:
>>>
>>>>
>>>> {# LANGUAGE RankNTypes, TypeFamilyDependencies #}
>>>>
>>>> class C a where
>>>>
>>>> type T a = b  b > a
>>>>
>>>> instance C Bool where
>>>>
>>>> type T Bool = Int
>>>>
>>>> type X b = forall a . T a ~ b => a
>>>>
>>>> x :: X Int
>>>> x = False
>>> I would expect this code to be accepted. However, I get
the
>>> following
>>> error message:
>>>
>>>>
>>>> A.hs:14:5: error:
>>>> Could not deduce: a ~ Bool
>>>> from the context: T a ~ Int
>>>> bound by the type signature for:
>>>> x :: T a ~ Int => a
>>>> at A.hs:13:110
>>>> a is a rigid type variable bound by
>>>> the type signature for:
>>>> x :: forall a. T a ~ Int => a
>>>> at A.hs:11:19
>>>> In the expression: False
>>>> In an equation for x: x = False
>>>> Relevant bindings include x :: a (bound at
A.hs:14:1)
>>> This is strange, since injectivity should exactly make
it possible
>>> to
>>> deduce a ~ Bool from T a ~ Int.
>>>
>>> Another example is this:
>>>
>>>>
>>>> {# LANGUAGE GADTs, TypeFamilyDependencies #}
>>>>
>>>> class C a where
>>>>
>>>> type T a = b  b > a
>>>>
>>>> instance C Bool where
>>>>
>>>> type T Bool = Int
>>>>
>>>> data G b where
>>>>
>>>> G :: Eq a => a > G (T a)
>>>>
>>>> instance Eq (G b) where
>>>>
>>>> G a1 == G a2 = a1 == a2a
>>> I would also expect this code to be accepted. However, I
get the
>>> following error message:
>>>
>>>>
>>>> B.hs:17:26: error:
>>>> Could not deduce: a1 ~ a
>>>> from the context: (b ~ T a, Eq a)
>>>> bound by a pattern with constructor:
>>>> G :: forall a. Eq a => a > G (T
a),
>>>> in an equation for ==
>>>> at B.hs:17:58
>>>> or from: (b ~ T a1, Eq a1)
>>>> bound by a pattern with constructor:
>>>> G :: forall a. Eq a => a > G (T
a),
>>>> in an equation for ==
>>>> at B.hs:17:1316
>>>> a1 is a rigid type variable bound by
>>>> a pattern with constructor: G :: forall a. Eq a
=> a > G
>>>> (T
>>>> a),
>>>> in an equation for ==
>>>> at B.hs:17:13
>>>> a is a rigid type variable bound by
>>>> a pattern with constructor: G :: forall a. Eq a
=> a > G
>>>> (T
>>>> a),
>>>> in an equation for ==
>>>> at B.hs:17:5
>>>> In the second argument of (==),
namely a2
>>>> In the expression: a1 == a2
>>>> In an equation for ==: (G a1) == (G
a2) = a1 == a2
>>>> Relevant bindings include
>>>> a2 :: a1 (bound at B.hs:17:15)
>>>> a1 :: a (bound at B.hs:17:7)
>>> If b ~ T a and b ~ T a1, then T a ~ T a1 and
subsequently a ~ a1,
>>> because
>>> of injectivity. Unfortunately, GHC does not join the two
contexts (b
>>> ~ T
>>> a, Eq a) and (b ~ T a1, Eq a1).
>>>
>>> Are these behaviors really intended, or are these bugs
showing up?
>>>
From rae at cs.brynmawr.edu Fri Jul 7 02:19:56 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 6 Jul 2017 22:19:56 0400
Subject: Heterogeneous equality
InReplyTo: <1499289802.2497.91.camel@jeltsch.info>
References: <1499289802.2497.91.camel@jeltsch.info>
MessageID:
> On Jul 5, 2017, at 5:23 PM, Wolfgang Jeltsch wrote:
>
> Hi!
>
> The base package contains the module Data.Type.Equality, which contains
> the type (:~:) for homogeneous equality. I was a bit surprised that
> there is no type for heterogeneous equality there. Is there such a type
> somewhere else in the standard library?
I don't believe it is, but (in my opinion) it should be.
>
> I tried to define a type for heterogeneous equality myself as follows:
>
>> {# LANGUAGE GADTs, PolyKinds, TypeOperators #}
>>
>> data a :~~: b where
>>
>> HRefl :: a :~~: a
>
> To my surprise, the kind of (:~~:) defined this way is k > k > *, not
> k > l > *. Why is this?
Because the definition of heterogeneous equality requires polymorphic recursion, in that the usage of (:~~:) in the type of HRefl has different kind indices than the declaration head. Polymorphic recursion is allowed only when you have a *complete usersupplied kind signature*, as documented here (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#completeusersuppliedkindsignaturesandpolymorphicrecursion).
This surprised me, too, when I first encountered it, but I believe it's the correct behavior.
Richard
From george.karachalias at gmail.com Sat Jul 15 10:48:41 2017
From: george.karachalias at gmail.com (gkaracha)
Date: Sat, 15 Jul 2017 03:48:41 0700 (MST)
Subject: Trouble with injective type families
InReplyTo: <45524D9C2026408DB88E6C3CA86C69A4@cs.brynmawr.edu>
References: <1499214064.2497.44.camel@jeltsch.info>
<1499261843.2497.48.camel@jeltsch.info>
<45524D9C2026408DB88E6C3CA86C69A4@cs.brynmawr.edu>
MessageID: <15001157212375860731.post@n5.nabble.com>
Me and Tom Schrijvers recently got a paper accepted at Haskell '17 concerning
the elaboration of functional dependencies in System FC *without extending
it*:
https://people.cs.kuleuven.be/~george.karachalias/papers/fundeps.pdf
The work is not currently implemented in GHC but we made some extra effort
to make our system GHCcompatible so that integration will be possible in
the future :) In addition to the elaboration of FDs, we also noticed that
they are unsound as currently implemented (Section 2.2 in the draft), if we
treat them as typelevel functions. Hence, we had to tighten up the
restrictions imposed on them, good thing that until now they didn't affect
the generated System FC code!
There is still some work to be done to transfer the results to injective
type families but I believe we are getting there :)
Cheers,
George

View this message in context: http://haskell.1045720.n5.nabble.com/Troublewithinjectivetypefamiliestp5860108p5860731.html
Sent from the Haskell  Glasgowhaskellusers mailing list archive at Nabble.com.
From ben at welltyped.com Sun Jul 23 03:03:28 2017
From: ben at welltyped.com (Ben Gamari)
Date: Sat, 22 Jul 2017 23:03:28 0400
Subject: [ANNOUNCE] GHC 8.2.1 available
MessageID: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
===============================================
The Glasgow Haskell Compiler  version 8.2.1
===============================================
The GHC developers are very happy to announce the longawaited 8.2.1
release of Glasgow Haskell Compiler. Binary and source distributions can
be found at
https://downloads.haskell.org/~ghc/8.2.1/
This is the second release in the 8.0 series. As such, the focus of this
release is performance, stability, and consolidation. Consequently
numerous cleanups can be seen throughout the compiler including,
* Significant improvements in compiler performance
* More robust support for levity polymorphism
* Reliable DWARF debugging information
* Improved runtime system performance on NUMA systems
* Retooling of the costcenter profiler, including support for live
streaming of profile data via the GHC event log
* Interface file determinism
* More robust treatment of join points, enabling significantly better
code generation in many cases
* Numerous improvements in robustness on Windows
* and the resolution of over 500 other tickets
In addition, there are a number of new features,
* A new, more typesafe type reflection mechanism
* The longawaited Backpack module system
* Deriving strategies to disambiguate between GHC's various instance
deriving mechanisms
* Unboxed sum types, for efficient unpacked representation of sum data
types
* Compact regions, allowing better control over garbage collection
in the presence of large heaps containing many longlived objects.
* Colorful messages and caret diagnostics for more legible errors
A more thorough list of the changes in this release can be found in the
release notes,
https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1notes.html
There are a few changes in releaseengineering that should be noted,
* Binary distributions for 32bit CentOS 6.7 have been dropped.
Moreover, there are no dedicated CentOS 7.0 distributions as CentOS 7
can use can use Debian 8 binaries. If you would like us to continue
to produce 32bit CentOS 6.7 distributions please let us know.
* GHC HQ now builds FreeBSD and OpenBSD distributions for amd64; this
comes after many years of these distributions being faithfully
provided by Karel Gardas and Pali Gabor Janos, who we should heartily
thank for their contributions.
GHC HQ building these distributions ourselves will allow us to more
quickly ship distributions to users by eliminating the need for a
long lag time between source release availability and having all
binary distributions available.
* There is a technologypreview of an AArch64 Linux binary
distribution, as well as an ARM Linux build. AArch64 support is quite
preliminary but should be stable in 8.4 thanks to further linker
fixes by Moritz Angerman. ARM should be stable.
* GHC now tries to use the gold and lld linkers by default. These
linkers are significantly faster than the BFD linker implementation
that most Linux distributions use by default. If gold or lld are not
available GHC will use the system's default linker. GHC can be forced
to use the default linker by passing disableldoverride to
configure.
This release has been the result of over a year of hard work by over 150
code contributors. Thanks to everyone who has helped in writing patches,
testing, reporting bugs, and offering feedback over the last year.
This release cycle was admittedly quite drawn out, significantly longer
than expected or desired. While we are confident that the result is
worth the wait, we have been steadily working on infrastructure which
should help shrink future release cycles and give us better testing
between releases. More details on this coming soon.
As always, let us know if you encounter trouble.
How to get it
~~~~~~~~~~~~~
The easy way is to go to the web page, which should be selfexplanatory:
http://www.haskell.org/ghc/
We supply binary builds in the native package format for many
platforms, and the source distribution is available from the same
place.
Packages will appear as they are built  if the package for your
system isn't available yet, please try again later.
Background
~~~~~~~~~~
Haskell is a standard lazy functional programming language.
GHC is a stateoftheart programming suite for Haskell. Included is
an optimising compiler generating efficient code for a variety of
platforms, together with an interactive system for convenient, quick
development. The distribution includes space and time profiling
facilities, a large collection of libraries, and support for various
language extensions, including concurrency, exceptions, and foreign
language interfaces. GHC is distributed under a BSDstyle open source license.
A wide variety of Haskell related resources (tutorials, libraries,
specifications, documentation, compilers, interpreters, references,
contact information, links to research groups) are available from the
Haskell home page (see below).
Online GHCrelated resources
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Relevant URLs on the WorldWide Web:
GHC home page http://www.haskell.org/ghc/
GHC developers' home page http://ghc.haskell.org/trac/ghc/
Haskell home page http://www.haskell.org/
Supported Platforms
~~~~~~~~~~~~~~~~~~~
The list of platforms we support, and the people responsible for them,
is here:
http://ghc.haskell.org/trac/ghc/wiki/Contributors
Ports to other platforms are possible with varying degrees of
difficulty. The Building Guide describes how to go about porting to a
new platform:
http://ghc.haskell.org/trac/ghc/wiki/Building
Developers
~~~~~~~~~~
We welcome new contributors. Instructions on accessing our source
code repository, and getting started with hacking on GHC, are
available from the GHC's developer's site run by Trac:
http://ghc.haskell.org/trac/ghc/
Mailing lists
~~~~~~~~~~~~~
We run mailing lists for GHC users and bug reports; to subscribe, use
the web interfaces at
http://mail.haskell.org/cgibin/mailman/listinfo/glasgowhaskellusers
http://mail.haskell.org/cgibin/mailman/listinfo/ghctickets
There are several other haskell and ghcrelated mailing lists on
www.haskell.org; for the full list, see
https://mail.haskell.org/cgibin/mailman/listinfo
Some GHC developers hang out on #haskell on IRC, too:
http://www.haskell.org/haskellwiki/IRC_channel
Please report bugs using our bug tracking system. Instructions on
reporting bugs can be found here:
http://www.haskell.org/ghc/reportabug
 next part 
A nontext attachment was scrubbed...
Name: signature.asc
Type: application/pgpsignature
Size: 487 bytes
Desc: not available
URL:
From ben at welltyped.com Sun Jul 23 13:41:31 2017
From: ben at welltyped.com (Ben Gamari)
Date: Sun, 23 Jul 2017 09:41:31 0400
Subject: [ANNOUNCE] GHC 8.2.1 available
InReplyTo: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
References: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
MessageID: <8760ejqnhw.fsf@benlaptop.smartcactus.org>
Minor editorial note (thanks to everyone who brought this to my attention):
The URL listed in the announcement for the release notes isn't quite
right. The release notes can be found at,
> https://haskell.org/ghc/docs/8.2.1/html/users_guide/8.2.1notes.html
>
Sorry for the confusion.
Cheers,
 Ben
 next part 
A nontext attachment was scrubbed...
Name: signature.asc
Type: application/pgpsignature
Size: 487 bytes
Desc: not available
URL:
From wolfgangit at jeltsch.info Tue Jul 25 22:01:45 2017
From: wolfgangit at jeltsch.info (Wolfgang Jeltsch)
Date: Wed, 26 Jul 2017 01:01:45 +0300
Subject: [ANNOUNCE] GHC 8.2.1 available
InReplyTo: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
References: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
MessageID: <1501020105.14379.125.camel@jeltsch.info>
Am Samstag, den 22.07.2017, 23:03 0400 schrieb Ben Gamari:
> In addition, there are a number of new features,
>
> * A new, more typesafe type reflection mechanism
>
> * The longawaited Backpack module system
>
> * Deriving strategies to disambiguate between GHC's various instance
> deriving mechanisms
>
> * Unboxed sum types, for efficient unpacked representation of sum
> data types
>
> * Compact regions, allowing better control over garbage collection
> in the presence of large heaps containing many longlived objects.
>
> * Colorful messages and caret diagnostics for more legible errors
>
> A more thorough list of the changes in this release can be found in
> the release notes,
>
> https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1notes.html
It seems that the release notes mention the new type reflection
mechanism und colorful messages only in the “Highlights” section, not in
the “Full details” section, and that they do not mention the Backpack
module system and unboxed sums at all.
All the best,
Wolfgang
From ben at smartcactus.org Wed Jul 26 14:15:00 2017
From: ben at smartcactus.org (Ben Gamari)
Date: Wed, 26 Jul 2017 10:15:00 0400
Subject: [ANNOUNCE] GHC 8.2.1 available
InReplyTo: <1501020105.14379.125.camel@jeltsch.info>
References: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
<1501020105.14379.125.camel@jeltsch.info>
MessageID: <87h8xzp9nf.fsf@benlaptop.smartcactus.org>
Wolfgang Jeltsch writes:
> Am Samstag, den 22.07.2017, 23:03 0400 schrieb Ben Gamari:
>> In addition, there are a number of new features,
>>
>> * A new, more typesafe type reflection mechanism
>>
>> * The longawaited Backpack module system
>>
>> * Deriving strategies to disambiguate between GHC's various instance
>> deriving mechanisms
>>
>> * Unboxed sum types, for efficient unpacked representation of sum
>> data types
>>
>> * Compact regions, allowing better control over garbage collection
>> in the presence of large heaps containing many longlived objects.
>>
>> * Colorful messages and caret diagnostics for more legible errors
>>
>> A more thorough list of the changes in this release can be found in
>> the release notes,
>>
>> https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1notes.html
>
> It seems that the release notes mention the new type reflection
> mechanism und colorful messages only in the “Highlights” section, not in
> the “Full details” section, and that they do not mention the Backpack
> module system and unboxed sums at all.
>
Yes, indeed these were oversights. They are fixed in the ghc8.2 branch
and I will try to push newly generated documentation shortly.
Cheers,
 Ben
 next part 
A nontext attachment was scrubbed...
Name: signature.asc
Type: application/pgpsignature
Size: 487 bytes
Desc: not available
URL:
From qdunkan at gmail.com Thu Jul 27 01:45:44 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed, 26 Jul 2017 18:45:44 0700
Subject: [ANNOUNCE] GHC 8.2.1 available
InReplyTo: <87h8xzp9nf.fsf@benlaptop.smartcactus.org>
References: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
<1501020105.14379.125.camel@jeltsch.info>
<87h8xzp9nf.fsf@benlaptop.smartcactus.org>
MessageID:
This seems like a silly question, but how can we install cabalinstall
now? The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 &&
<1.25), but it looks like ghc Cabal is now at 2.*.
I ran into this because if I get:
% cabal install onlydependencies
Resolving dependencies...
cabal: internal error when reading package index: failed to parse .cabal
fileThe package index or index cache is probably corrupt. Running cabal update
might fix it.
It seems to be triggered by having 'ekg' in the deps list, since if I
take it out then I get some other errors about packages not liking the
new base, which is true. 'ekg' also doesn't like the new base, but
"internal error" is not the clearest way to express that :)
It's frustrating that cabalinstall still doesn't report the parse
error, even though the parse function returns one. It just ignores
the ParseFailed case. I was going to try fixing it and send a pull
request when I ran into the Cabal 2.* problem.
On Wed, Jul 26, 2017 at 7:15 AM, Ben Gamari wrote:
> Wolfgang Jeltsch writes:
>
>> Am Samstag, den 22.07.2017, 23:03 0400 schrieb Ben Gamari:
>>> In addition, there are a number of new features,
>>>
>>> * A new, more typesafe type reflection mechanism
>>>
>>> * The longawaited Backpack module system
>>>
>>> * Deriving strategies to disambiguate between GHC's various instance
>>> deriving mechanisms
>>>
>>> * Unboxed sum types, for efficient unpacked representation of sum
>>> data types
>>>
>>> * Compact regions, allowing better control over garbage collection
>>> in the presence of large heaps containing many longlived objects.
>>>
>>> * Colorful messages and caret diagnostics for more legible errors
>>>
>>> A more thorough list of the changes in this release can be found in
>>> the release notes,
>>>
>>> https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1notes.html
>>
>> It seems that the release notes mention the new type reflection
>> mechanism und colorful messages only in the “Highlights” section, not in
>> the “Full details” section, and that they do not mention the Backpack
>> module system and unboxed sums at all.
>>
> Yes, indeed these were oversights. They are fixed in the ghc8.2 branch
> and I will try to push newly generated documentation shortly.
>
> Cheers,
>
>  Ben
>
> _______________________________________________
> Glasgowhaskellusers mailing list
> Glasgowhaskellusers at haskell.org
> http://mail.haskell.org/cgibin/mailman/listinfo/glasgowhaskellusers
>
From wolfgangit at jeltsch.info Thu Jul 27 02:01:22 2017
From: wolfgangit at jeltsch.info (Wolfgang Jeltsch)
Date: Thu, 27 Jul 2017 05:01:22 +0300
Subject: [ANNOUNCE] GHC 8.2.1 available
InReplyTo:
References: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
<1501020105.14379.125.camel@jeltsch.info>
<87h8xzp9nf.fsf@benlaptop.smartcactus.org>
MessageID: <1501120882.2815.104.camel@jeltsch.info>
Hi!
I ran into the same problem.
Apparently, we need cabalinstall 2.0, which has not been released yet.
A preliminary solution is to use the development version from the 2.0
branch. Binary packages can be found at
http://ppa.launchpad.net/hvr/ghc/ubuntu/pool/main/c/cabalinstall2.0/ ,
for example. It is possible to extract the cabalinstall executable from
these packages, so that it can be installed without using some Linux
distribution package manager.
All the best,
Wolfgang
Am Mittwoch, den 26.07.2017, 18:45 0700 schrieb Evan Laforge:
> This seems like a silly question, but how can we install cabalinstall
> now? The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 &&
> <1.25), but it looks like ghc Cabal is now at 2.*.
>
> I ran into this because if I get:
>
> % cabal install onlydependencies
> Resolving dependencies...
> cabal: internal error when reading package index: failed to parse
> .cabal
> fileThe package index or index cache is probably corrupt. Running
> cabal update
> might fix it.
>
> It seems to be triggered by having 'ekg' in the deps list, since if I
> take it out then I get some other errors about packages not liking the
> new base, which is true. 'ekg' also doesn't like the new base, but
> "internal error" is not the clearest way to express that :)
>
> It's frustrating that cabalinstall still doesn't report the parse
> error, even though the parse function returns one. It just ignores
> the ParseFailed case. I was going to try fixing it and send a pull
> request when I ran into the Cabal 2.* problem.
>
> On Wed, Jul 26, 2017 at 7:15 AM, Ben Gamari
> wrote:
> >
> > Wolfgang Jeltsch writes:
> >
> > >
> > > Am Samstag, den 22.07.2017, 23:03 0400 schrieb Ben Gamari:
> > > >
> > > > In addition, there are a number of new features,
> > > >
> > > > * A new, more typesafe type reflection mechanism
> > > >
> > > > * The longawaited Backpack module system
> > > >
> > > > * Deriving strategies to disambiguate between GHC's various
> > > > instance
> > > > deriving mechanisms
> > > >
> > > > * Unboxed sum types, for efficient unpacked representation of
> > > > sum
> > > > data types
> > > >
> > > > * Compact regions, allowing better control over garbage
> > > > collection
> > > > in the presence of large heaps containing many longlived
> > > > objects.
> > > >
> > > > * Colorful messages and caret diagnostics for more legible
> > > > errors
> > > >
> > > > A more thorough list of the changes in this release can be found
> > > > in
> > > > the release notes,
> > > >
> > > > https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1
> > > > notes.html
> > > It seems that the release notes mention the new type reflection
> > > mechanism und colorful messages only in the “Highlights” section,
> > > not in
> > > the “Full details” section, and that they do not mention the
> > > Backpack
> > > module system and unboxed sums at all.
> > >
> > Yes, indeed these were oversights. They are fixed in the ghc8.2
> > branch
> > and I will try to push newly generated documentation shortly.
> >
> > Cheers,
> >
> >  Ben
> >
> > _______________________________________________
> > Glasgowhaskellusers mailing list
> > Glasgowhaskellusers at haskell.org
> > http://mail.haskell.org/cgibin/mailman/listinfo/glasgowhaskelluse
> > rs
> >
From qdunkan at gmail.com Thu Jul 27 18:19:10 2017
From: qdunkan at gmail.com (Evan Laforge)
Date: Thu, 27 Jul 2017 11:19:10 0700
Subject: [ANNOUNCE] GHC 8.2.1 available
InReplyTo: <1501120882.2815.104.camel@jeltsch.info>
References: <87bmobrh1b.fsf@benlaptop.smartcactus.org>
<1501020105.14379.125.camel@jeltsch.info>
<87h8xzp9nf.fsf@benlaptop.smartcactus.org>
<1501120882.2815.104.camel@jeltsch.info>
MessageID:
Thanks for the reply. I got cabalinstall from
https://github.com/haskell/cabal/ and assumed it was the latest
version... but now that I look carefully I see it has a 2.0 branch. I
compiled it and I don't get that confusing "parse error" any more. It
looks like a nicer error message in general too (except still missing
some spaces, specifically "After searching the rest of the dependency
tree exhaustively, these were the goals I've had most trouble
fulfilling: karya, ekgTrying configure anyway."), so that's probably
thanks to the solver improvements in 2.0.
Since it's apparently just a bug in older cabalinstalls I guess I
won't bother trying to find it.
On Wed, Jul 26, 2017 at 7:01 PM, Wolfgang Jeltsch
wrote:
> Hi!
>
> I ran into the same problem.
>
> Apparently, we need cabalinstall 2.0, which has not been released yet.
> A preliminary solution is to use the development version from the 2.0
> branch. Binary packages can be found at
>
> http://ppa.launchpad.net/hvr/ghc/ubuntu/pool/main/c/cabalinstall2.0/ ,
>
> for example. It is possible to extract the cabalinstall executable from
> these packages, so that it can be installed without using some Linux
> distribution package manager.
>
> All the best,
> Wolfgang
>
> Am Mittwoch, den 26.07.2017, 18:45 0700 schrieb Evan Laforge:
>> This seems like a silly question, but how can we install cabalinstall
>> now? The latest hackage version 1.24.0.2 has Cabal (>=1.24.2 &&
>> <1.25), but it looks like ghc Cabal is now at 2.*.
>>
>> I ran into this because if I get:
>>
>> % cabal install onlydependencies
>> Resolving dependencies...
>> cabal: internal error when reading package index: failed to parse
>> .cabal
>> fileThe package index or index cache is probably corrupt. Running
>> cabal update
>> might fix it.
>>
>> It seems to be triggered by having 'ekg' in the deps list, since if I
>> take it out then I get some other errors about packages not liking the
>> new base, which is true. 'ekg' also doesn't like the new base, but
>> "internal error" is not the clearest way to express that :)
>>
>> It's frustrating that cabalinstall still doesn't report the parse
>> error, even though the parse function returns one. It just ignores
>> the ParseFailed case. I was going to try fixing it and send a pull
>> request when I ran into the Cabal 2.* problem.
>>
>> On Wed, Jul 26, 2017 at 7:15 AM, Ben Gamari
>> wrote:
>> >
>> > Wolfgang Jeltsch writes:
>> >
>> > >
>> > > Am Samstag, den 22.07.2017, 23:03 0400 schrieb Ben Gamari:
>> > > >
>> > > > In addition, there are a number of new features,
>> > > >
>> > > > * A new, more typesafe type reflection mechanism
>> > > >
>> > > > * The longawaited Backpack module system
>> > > >
>> > > > * Deriving strategies to disambiguate between GHC's various
>> > > > instance
>> > > > deriving mechanisms
>> > > >
>> > > > * Unboxed sum types, for efficient unpacked representation of
>> > > > sum
>> > > > data types
>> > > >
>> > > > * Compact regions, allowing better control over garbage
>> > > > collection
>> > > > in the presence of large heaps containing many longlived
>> > > > objects.
>> > > >
>> > > > * Colorful messages and caret diagnostics for more legible
>> > > > errors
>> > > >
>> > > > A more thorough list of the changes in this release can be found
>> > > > in
>> > > > the release notes,
>> > > >
>> > > > https://haskell.org/ghc/docs/8.2.1/docs/html/users_guide/8.2.1
>> > > > notes.html
>> > > It seems that the release notes mention the new type reflection
>> > > mechanism und colorful messages only in the “Highlights” section,
>> > > not in
>> > > the “Full details” section, and that they do not mention the
>> > > Backpack
>> > > module system and unboxed sums at all.
>> > >
>> > Yes, indeed these were oversights. They are fixed in the ghc8.2
>> > branch
>> > and I will try to push newly generated documentation shortly.
>> >
>> > Cheers,
>> >
>> >  Ben
>> >
>> > _______________________________________________
>> > Glasgowhaskellusers mailing list
>> > Glasgowhaskellusers at haskell.org
>> > http://mail.haskell.org/cgibin/mailman/listinfo/glasgowhaskelluse
>> > rs
>> >