- ghc-devs - Haskell.org

Cmm comments are not Haddock comments---should this change?
by Norman Ramsey 20 Oct '21

20 Oct '21

The definitions of the Cmm data structures are richly commented in the source code, but the comments are not Haddock comments, so the information doesn't make it into the Haddock documentation. As I refresh my memory about Cmm, I'm thinking of converting the existing comments to Haddock comments. The only downside I can think of is that the Haddock pages may appear more cluttered. Is there any reason I should refrain? Norman

2 2

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

19 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 14 Oct '21

14 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 13 Oct '21

13 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