- ghc-devs - Haskell.org

gitlab.haskell.org
by Simon Peyton Jones 18 Oct '21

18 Oct '21

I'm getting "502" from gitlab.haskell.org. Is it just me? Thanks Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj(a)microsoft.com<mailto:simonpj@microsoft.com> will cease to work. Use simon.peytonjones(a)gmail.com<mailto:simon.peytonjones@gmail.com> instead. (For now, it just forwards to simonpj(a)microsoft.com.)

5 4

GHC.StgToCmm.Monad documentation out of sync?
by Norman Ramsey 18 Oct '21

18 Oct '21

All, I'm looking at the paragraph starting on line 271 of GHC.StgToCmm.Monad, which purports to explain ReturnKind. But the labels mentioned in the paragraph don't seem to match the preceding code example. Also, I don't understand why only one branch of the `case` expression seems to be protected by a heap-limit check. I understand what I'm seeing well enough to fear that something is wrong, but not well enough to fix it. Is someone else willing to have a look and maybe we can repair the documentation together? Noramn

2 1

GitLab outage
by Ben Gamari 18 Oct '21

18 Oct '21

Hello all, Unfortunately yesterday gitlab.haskell.org yet again ran out of disk space. It is currently being migrated to another machine and in the meantime things may be a bit flaky. Many apologies for the inconvenience. More updates will be coming as the situation develops. Cheers, - Ben

2 3

Re: To allow deriving poly-kinded Generic1 instances
by Ryan Scott 13 Oct '21

13 Oct '21

> I figured out that this compiles: > > data HKD (f :: Type -> Type) = Foo (F1 Int f) (F1 Double f) > | Bar (F1 Bool f) > deriving Generic1 > > newtype F1 a f = F1 { unF1 :: f a } Yes, that's a useful trick to keep in mind. For what it's worth, I think your `F1` is the same thing as `Barbie` [1] from the `barbies` library. > Would it be a good idea to add F1 to GHC.Generics? There's a couple of issues that make me cautious about this idea: 1. This isn't an issue that's specific to `DeriveGeneric`. Other `stock` deriving strategies that deal with similar classes, such as `DeriveFunctor`, also suffer from this problem. For instance, you can't do the following: > data T a = MkT (Either a Int) deriving Functor Again, the issue is that the last type parameter (`a`) appears in a field type in a position other than as the last argument. To make _this_ work, you'd need something like `Flip` [2] from the `bifunctors` library: > data T a = MkT (Flip Either Int a) deriving Functor That leads into the second issue... 2. There are an infinite number of different type variable combinations you could conceivably add special support for. I've already mentioned `Barbie` and `Flip` above, but you could just as well put the last type parameter in other places as well: > data S1 a = MkS1 (a, Int, Int) deriving Generic1 > data S2 a = MkS2 (a, Int, Int, Int) deriving Generic1 > data S3 a = MkS3 (a, Int, Int, Int, Int) deriving Generic1 > ... And this is only if you assume that the last type parameter only appears once in each field type. You'd need even more special cases if the last type parameter appears in multiple places in a field type: > data U1 a = MkU1 (a, a) deriving Generic1 > data U2 a = MkU2 (a, a, a) deriving Generic1 > ... With all of these possibilities, it's difficult to say how far we should go with this. Generally speaking, my recommendation for people who are dissatisfied with `Generic1`'s restrictions on where the last type parameter can be placed is to not use `Generic1` at all. There are other generic programming libraries that do not have the same restrictions, such as `kind-generics` [3]. Using something like `kind-generics` avoids the need to use things like `Barbie`, `Flip`, etc. in the first place. Best, Ryan ----- [1] https://hackage.haskell.org/package/barbies-2.0.3.0/docs/Barbies.html#t:Bar… [2] https://hackage.haskell.org/package/bifunctors-5.5.11/docs/Data-Bifunctor-F… [3] https://hackage.haskell.org/package/kind-generics On Wed, Oct 13, 2021 at 9:26 AM Fumiaki Kinoshita <fumiexcel(a)gmail.com> wrote: > Oh, I drew a conclusion too early when fiddling with a hypothetical > Generic1 instance. I now think it's not possible to define an instance with > the current kit. > > I figured out that this compiles: > > data HKD (f :: Type -> Type) = Foo (F1 Int f) (F1 Double f) > | Bar (F1 Bool f) > deriving Generic1 > > newtype F1 a f = F1 { unF1 :: f a } > > Problem solved, thanks! > > Would it be a good idea to add F1 to GHC.Generics? Omitting metadata, it'd > derive something like > > instance Generic1 HKD where > type Rep1 HKD = F1 Int :*: F1 Double :+: F1 Bool > from1 (Foo a b) = L1 (F1 a :*: F1 b) > from1 (Bar c) = R1 (F1 c) > to1 (L1 (F1 a :*: F1 b)) = Foo a b > to1 (R1 (F1 c)) = Bar c > > I suppose it doesn't affect existing Generic1 instances and uses, so I > don't expect breakages by adding this > > ... >

2 1

Re: To allow deriving poly-kinded Generic1 instances
by Ryan Scott 13 Oct '21

13 Oct '21

Thanks for posting an example—that's very helpful to figure out what is going on. > Currently, GHC rejects the following code: > > {-# LANGUAGE DeriveGeneric #-} > {-# LANGUAGE PolyKinds #-} > import GHC.Generics > > data HKD f = Foo (f Int) (f Double) > | Bar (f Bool) > deriving Generic1 > The compilation error is > > • Can't make a derived instance of ‘Generic1 HKD’: > Constructor ‘Foo’ applies a type to an argument involving the last parameter > but the applied type is not of kind * -> *, and > Constructor ‘Foo’ applies a type to an argument involving the last parameter > but the applied type is not of kind * -> *, and > Constructor ‘Bar’ applies a type to an argument involving the last parameter > but the applied type is not of kind * -> * > • In the data declaration for ‘HKD’ I see. That error message could be worded better, in my opinion. The issue really isn't so much about the kind of `f`. If you had written `data HKD (f :: Type -> Type) = Baz (Proxy f)`, for instance, I would expect it to work. The real issue is _where_ `f` appears in the data constructors. In `Bar`, for instance, you have: > Bar (f Bool) `Generic1` is limited to data types where the last type parameter only appears as the last type argument in any field. This means that a field like `Proxy f` would be fine, as that would be represented as `Rec1 Proxy` in a `Rep1` instance. `f Bool`, on the other hand, is problematic. `GHC.Generics` doesn't have a representation type that simultaneously allows representing this field while also "focusing" on the last type parameter like `Rec1`, `Par1`, etc. would allow. The `Foo` constructor has similar issues. The error-reporting machinery for `DeriveGeneric` essentially just accumulates every issue it encounters and reports everything at once, which is why there is a duplicate error message involving `Foo`. Needless to say, this kind of error message could be improved. > Although it is possible to define a hand-rolled instance of Generic1 Really? I'm not sure how you would define a correct `Generic1` instance for `HKD` at all. What did you have in mind? Best, Ryan On Wed, Oct 13, 2021 at 8:33 AM Fumiaki Kinoshita <fumiexcel(a)gmail.com> wrote: > Currently, GHC rejects the following code: > > {-# LANGUAGE DeriveGeneric #-} > {-# LANGUAGE PolyKinds #-} > import GHC.Generics > > data HKD f = Foo (f Int) (f Double) > | Bar (f Bool) > deriving Generic1 > > The compilation error is > > • Can't make a derived instance of ‘Generic1 HKD’: > Constructor ‘Foo’ applies a type to an argument involving the last > parameter > but the applied type is not of kind * -> *, and > Constructor ‘Foo’ applies a type to an argument involving the last > parameter > but the applied type is not of kind * -> *, and > Constructor ‘Bar’ applies a type to an argument involving the last > parameter > but the applied type is not of kind * -> * > • In the data declaration for ‘HKD’ > | > 7 | deriving Generic1 > > Although it is possible to define a hand-rolled instance of Generic1, > DeriveGeneric is still restricted to Type -> Type. > > 2021年10月13日(水) 21:17 Ryan Scott <ryan.gl.scott(a)gmail.com>: > >> Hello, >> >> I'm not quite sure I understand the issue you're hitting. Generic1 is >> poly-kinded, so I would expect it to be able to handle data types where the >> last type parameter has differing kinds. Can you post a complete example of >> the program you expect to typecheck, but doesn't? >> >> Best, >> >> Ryan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >

1 0

Re: To allow deriving poly-kinded Generic1 instances
by Ryan Scott 13 Oct '21

13 Oct '21

Hello, I'm not quite sure I understand the issue you're hitting. Generic1 is poly-kinded, so I would expect it to be able to handle data types where the last type parameter has differing kinds. Can you post a complete example of the program you expect to typecheck, but doesn't? Best, Ryan

1 0

GitLab summary note on review
by Richard Eisenberg 12 Oct '21

12 Oct '21

Hi devs, I've frequently wanted to attach a summary note to a review, unattached to any line of code. I thought this was impossible, but I see how to do it now. After making your review, with perhaps many line comments, go back to the Overview pane. Then, you can write a comment at the bottom, and, critically, add it to the review. Then, when you submit the review, the summary comment goes with it. Happy reviewing, Richard

2 1

how does a CAF become unreachable?
by Norman Ramsey 12 Oct '21

12 Oct '21

I spent the afternoon spelunking through some code and the Commentary, and I'm wondering how a CAF becomes unreachable. I gather it might have to do with GHC floating a static expression out of a context until it becomes a CAF, but I'm still not seeing how a CAF could at one point be reachable, then dynamically become unreachable. Can anyone show an example? Norman

2 1

where to go for HLS details?
by Norman Ramsey 12 Oct '21

12 Oct '21

Where is the place to go to talk details of the Haskell Language Server? I'm using the HLS with the GHC I have compiled from HEAD, and I am sitting on a number of difficulties: - When a project is compiled against a Stage 1 `base` library (as opposed to the one shipped with the bootstrap compiler), I am not always getting the documentation I expect. - The HLint part of the HLS seems to struggle finding modules in nested directories. - I cannot seem to get the `hiedb` command to index any files. - I'd like to set up the HLS to get to documentation via an HTTP-ish URL rather than the file:// URL that it is currently using, so that `doc-index.json` can be loaded successfully. I'm not quite ready to open a Github issue for any of these troubles just yet, but I'm not sure I can make progress on my own. Where is a good place to go for help? Norman

4 5

To allow deriving poly-kinded Generic1 instances
by Fumiaki Kinoshita 12 Oct '21

12 Oct '21

I was hacking GHC to see if it's able to derive Generic1 instance for datatypes with kind (Type -> Type) -> Type by omitting some checks. I noticed that the type parameter is substituted by GHC.Types.Any, preventing higher-kinded instances from typechecking. I found a comment implying that this is intentional; in GHC.Tc.Deriv.Generic.hs:977, Alternatively, we could have avoided this problem by expanding all type synonyms on the RHSes of Rep1 instances. But we might blow up the size of these types even further by doing this, so we choose not to do so. It wasn't obvious to me if binding a parameter in the type synonym instance declaration of Rep1 cause problems, because that's what I'd do if I were to define an instance by hand. Is there any offending example? I'm also trying to make such change myself (it doesn't add a type parameter and I'm not sure why) https://gitlab.haskell.org/fumieval/ghc/-/commit/bfe7766af80d90590b6b032d18…

1 0