From lists at richarde.dev Mon Jan 3 18:23:48 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 3 Jan 2022 18:23:48 +0000 Subject: convention around pattern synonyms In-Reply-To: References: <010f017e071c9e25-632a3872-29de-4e3a-b0f1-70cdc000c22f-000000@us-east-2.amazonses.com> <010f017e083bbdc6-f5fdb718-cf4a-4e60-9e4c-5cce52e925a0-000000@us-east-2.amazonses.com> <010f017e0c3c5bfc-d0067ada-d408-4594-ba2a-446cd4f13fd1-000000@us-east-2.amazonses.com> Message-ID: <010f017e212ee363-67bb3b69-d294-4c60-96f9-f20a0d78b157-000000@us-east-2.amazonses.com> > On Dec 30, 2021, at 3:25 PM, Viktor Dukhovni wrote: > > Perhaps my assumption that TH types directly mirror the internal AST is > not correct... A recent user-visible change is in `ConP` Many TH types are modeled after GHC-internal types, but this is just a matter of convenience, not necessity. (The necessity -- if we are to maintain feature parity in TH -- is that the same information is representable in both sets of types, not that the representations are the same.) So the convention I'm proposing here wouldn't affect TH. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From nr at cs.tufts.edu Wed Jan 12 00:02:29 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Tue, 11 Jan 2022 19:02:29 -0500 Subject: Semantics of Cmm `switch` statement? Message-ID: <20220112000229.CF6882C2771@homedog.cs.tufts.edu> For testing purposes, I created the following Cmm program: myswitch (bits32 n) { switch [0 .. 4] n { case 0, 1: { foreign "C" A(); } case 2: { foreign "C" B(); } case 4: { foreign "C" C(); } default: { foreign "C" D(); } } return (666); } In the original C-- specification, it's pretty clear that when, say, the call to foreign function `A` terminates, the switch statement is supposed to finish and function `myswitch` is supposed to return 666. What actually happens in GHC is that this source code is parsed into a control-flow graph in which execution loops forever, repeating the call. The relevant fragment of the prettyprinted CFG looks like this: {offset ca: // global _c1::I32 = %MO_XX_Conv_W64_W32(R1); //tick src switch [0 .. 4] _c1::I32 { case 0, 1 : goto c5; case 2 : goto c7; case 4 : goto c9; default: {goto c3;} } ... c5: // global //tick src _c4::I64 = A; call "ccall" arg hints: [] result hints: [] (_c4::I64)(); goto c5; ... } Surprising, at least to me. Is this behavior a bug or a feature? And if it is a feature, can anyone explain it to me? Norman From klebinger.andreas at gmx.at Wed Jan 12 02:10:06 2022 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Wed, 12 Jan 2022 03:10:06 +0100 Subject: Semantics of Cmm `switch` statement? In-Reply-To: <20220112000229.CF6882C2771@homedog.cs.tufts.edu> References: <20220112000229.CF6882C2771@homedog.cs.tufts.edu> Message-ID: Hi Norman, I vaguely remember that we "finish" such unterminated code blocks by jumping to the block again. That is for code like this:     myswitch2 (bits32 n) {       foreign "C" D();     } We produce code like this:     {       cg: call "ccall" arg hints:  []  result hints:  [] D();           goto cg;     } Instead of blowing up the compiler at compile time or the program at runtime. For switch statements I think blocks are just syntactic sugar. E.g. if you write case n: { } it's treated as if you wrote case n: jmp codeBlock; ... codeBlock:     And since your blocks don't terminate we get the behaviour you are seeing. But I haven't looked at any of the code related to this so it's possible I got it wrong. Cheers Andreas Am 12/01/2022 um 01:02 schrieb Norman Ramsey: > For testing purposes, I created the following Cmm program: > > myswitch (bits32 n) { > switch [0 .. 4] n { > case 0, 1: { foreign "C" A(); } > case 2: { foreign "C" B(); } > case 4: { foreign "C" C(); } > default: { foreign "C" D(); } > } > return (666); > } > > In the original C-- specification, it's pretty clear that when, say, > the call to foreign function `A` terminates, the switch statement is > supposed to finish and function `myswitch` is supposed to return 666. > What actually happens in GHC is that this source code is parsed into a > control-flow graph in which execution loops forever, repeating the > call. The relevant fragment of the prettyprinted CFG looks like this: > > {offset > ca: // global > _c1::I32 = %MO_XX_Conv_W64_W32(R1); > //tick src > switch [0 .. 4] _c1::I32 { > case 0, 1 : goto c5; > case 2 : goto c7; > case 4 : goto c9; > default: {goto c3;} > } > ... > c5: // global > //tick src > _c4::I64 = A; > call "ccall" arg hints: [] result hints: [] (_c4::I64)(); > goto c5; > ... > } > > Surprising, at least to me. > > Is this behavior a bug or a feature? And if it is a feature, can > anyone explain it to me? > > > Norman > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From trupill at gmail.com Thu Jan 13 14:19:34 2022 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 13 Jan 2022 15:19:34 +0100 Subject: Strictness/demand info for a Name Message-ID: Dear all, I’m trying to bring the information about demand and strictness to the Haskell Language Server, but I cannot find a way to do so. I was wondering whether you could help me :) Here’s my understanding; please correct me if I’m wrong: - The analysis runs on Core, so getting this information for the current file would require to run the compiler further than type checking, which is quite expensive, - However, this analysis should somehow use known information about imported functions, which should be readily available somewhere, - If the above is true, what is the simplest way to get the information for imported things? As I mentioned above, I would prefer not to run the compiler further than the type checking phase, since otherwise it gets too expensive for IDE usage. Right now HLS uses the information from the .hie files. In fact, this goes into the more general question of how to show information from different analyses within the IDE; I guess solving the case for strictness/analysis may open the door to more (maybe everything recorded inside a `Id`?) Regards, Alejandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Thu Jan 13 14:38:29 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 13 Jan 2022 14:38:29 +0000 Subject: Strictness/demand info for a Name In-Reply-To: References: Message-ID: You look at `dmdSigInfo` in `IdInfo`. Matt On Thu, Jan 13, 2022 at 2:20 PM Alejandro Serrano Mena wrote: > > Dear all, > > I’m trying to bring the information about demand and strictness to the Haskell Language Server, but I cannot find a way to do so. I was wondering whether you could help me :) > > Here’s my understanding; please correct me if I’m wrong: > > The analysis runs on Core, so getting this information for the current file would require to run the compiler further than type checking, which is quite expensive, > However, this analysis should somehow use known information about imported functions, which should be readily available somewhere, > If the above is true, what is the simplest way to get the information for imported things? As I mentioned above, I would prefer not to run the compiler further than the type checking phase, since otherwise it gets too expensive for IDE usage. Right now HLS uses the information from the .hie files. > > > In fact, this goes into the more general question of how to show information from different analyses within the IDE; I guess solving the case for strictness/analysis may open the door to more (maybe everything recorded inside a `Id`?) > > Regards, > Alejandro > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From sgraf1337 at gmail.com Thu Jan 13 14:45:29 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Thu, 13 Jan 2022 14:45:29 +0000 Subject: Strictness/demand info for a Name In-Reply-To: References: Message-ID: Yes, Matt is right. `dmdSigInfo` describes the how a function Id uses its arguments and free variables, whereas `demandInfo` describes how a (local, mostly) Id is used. Note that if you wanted to go beyond type-checking, you could probably run the analysis on the desugaring of the current module quite easily. But the results would be misleading, as prior optimisations (that you probably don't want to run) may arrange the program in a way that demand analysis has an easier time. ------ Originalnachricht ------ Von: "Matthew Pickering" An: "Alejandro Serrano Mena" Cc: "GHC developers" Gesendet: 13.01.2022 15:38:29 Betreff: Re: Strictness/demand info for a Name >You look at `dmdSigInfo` in `IdInfo`. > >Matt > >On Thu, Jan 13, 2022 at 2:20 PM Alejandro Serrano Mena > wrote: >> >> Dear all, >> >> I’m trying to bring the information about demand and strictness to the Haskell Language Server, but I cannot find a way to do so. I was wondering whether you could help me :) >> >> Here’s my understanding; please correct me if I’m wrong: >> >> The analysis runs on Core, so getting this information for the current file would require to run the compiler further than type checking, which is quite expensive, >> However, this analysis should somehow use known information about imported functions, which should be readily available somewhere, >> If the above is true, what is the simplest way to get the information for imported things? As I mentioned above, I would prefer not to run the compiler further than the type checking phase, since otherwise it gets too expensive for IDE usage. Right now HLS uses the information from the .hie files. >> >> >> In fact, this goes into the more general question of how to show information from different analyses within the IDE; I guess solving the case for strictness/analysis may open the door to more (maybe everything recorded inside a `Id`?) >> >> Regards, >> Alejandro >> _______________________________________________ >> ghc-devs mailing list >>ghc-devs at haskell.org >>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From trupill at gmail.com Thu Jan 13 15:43:50 2022 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 13 Jan 2022 16:43:50 +0100 Subject: Strictness/demand info for a Name In-Reply-To: References: Message-ID: Thanks for the pointers! :) Knowing this, let me maybe rephrase my question: is it possible to get demand information of identifiers *without* running the analysis itself? Alejandro El 13 ene 2022 15:45:29, Sebastian Graf escribió: > Yes, Matt is right. > > `dmdSigInfo` describes the how a function Id uses its arguments and free > variables, whereas > `demandInfo` describes how a (local, mostly) Id is used. > > Note that if you wanted to go beyond type-checking, you could probably > run the analysis on the desugaring of the current module quite easily. > But the results would be misleading, as prior optimisations (that you > probably don't want to run) may arrange the program in a way that demand > analysis has an easier time. > > ------ Originalnachricht ------ > Von: "Matthew Pickering" > An: "Alejandro Serrano Mena" > Cc: "GHC developers" > Gesendet: 13.01.2022 15:38:29 > Betreff: Re: Strictness/demand info for a Name > > You look at `dmdSigInfo` in `IdInfo`. > > > Matt > > > On Thu, Jan 13, 2022 at 2:20 PM Alejandro Serrano Mena > > wrote: > > > > > > Dear all, > > > > > > I’m trying to bring the information about demand and strictness to the > Haskell Language Server, but I cannot find a way to do so. I was wondering > whether you could help me :) > > > > > > Here’s my understanding; please correct me if I’m wrong: > > > > > > The analysis runs on Core, so getting this information for the current > file would require to run the compiler further than type checking, which is > quite expensive, > > > However, this analysis should somehow use known information about > imported functions, which should be readily available somewhere, > > > If the above is true, what is the simplest way to get the information > for imported things? As I mentioned above, I would prefer not to run the > compiler further than the type checking phase, since otherwise it gets too > expensive for IDE usage. Right now HLS uses the information from the .hie > files. > > > > > > > > > In fact, this goes into the more general question of how to show > information from different analyses within the IDE; I guess solving the > case for strictness/analysis may open the door to more (maybe everything > recorded inside a `Id`?) > > > > > > Regards, > > > Alejandro > > > _______________________________________________ > > > ghc-devs mailing list > > >ghc-devs at haskell.org > > >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Thu Jan 13 15:50:01 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Thu, 13 Jan 2022 15:50:01 +0000 Subject: Strictness/demand info for a Name In-Reply-To: References: Message-ID: Yes, every imported identifier from a module that was compiled with optimisations should have the proper analysis information in its IdInfo. So if you have `base` somewhere in one of your compiled libraries and load it, then the identifier of `GHC.OldList.map` will have an `idDmdSig` that says it's strict in the list parameter. At least that's how it works in GHC, where these IdInfos are populated with the information from the loaded interface files. The situation with HLS might be different, although I wouldn't expect that. ------ Originalnachricht ------ Von: "Alejandro Serrano Mena" An: "Sebastian Graf" Cc: "GHC developers" ; "Matthew Pickering" Gesendet: 13.01.2022 16:43:50 Betreff: Re: Re[2]: Strictness/demand info for a Name >Thanks for the pointers! :) > >Knowing this, let me maybe rephrase my question: is it possible to get >demand information of identifiers without running the analysis itself? > >Alejandro > >El 13 ene 2022 15:45:29, Sebastian Graf escribió: >>Yes, Matt is right. >> >>`dmdSigInfo` describes the how a function Id uses its arguments and >>free >>variables, whereas >>`demandInfo` describes how a (local, mostly) Id is used. >> >>Note that if you wanted to go beyond type-checking, you could probably >>run the analysis on the desugaring of the current module quite easily. >>But the results would be misleading, as prior optimisations (that you >>probably don't want to run) may arrange the program in a way that >>demand >>analysis has an easier time. >> >>------ Originalnachricht ------ >>Von: "Matthew Pickering" >>An: "Alejandro Serrano Mena" >>Cc: "GHC developers" >>Gesendet: 13.01.2022 15:38:29 >>Betreff: Re: Strictness/demand info for a Name >> >>>You look at `dmdSigInfo` in `IdInfo`. >>> >>>Matt >>> >>>On Thu, Jan 13, 2022 at 2:20 PM Alejandro Serrano Mena >>> wrote: >>> > >>> > Dear all, >>> > >>> > I’m trying to bring the information about demand and strictness to >>>the Haskell Language Server, but I cannot find a way to do so. I was >>>wondering whether you could help me :) >>> > >>> > Here’s my understanding; please correct me if I’m wrong: >>> > >>> > The analysis runs on Core, so getting this information for the >>>current file would require to run the compiler further than type >>>checking, which is quite expensive, >>> > However, this analysis should somehow use known information about >>>imported functions, which should be readily available somewhere, >>> > If the above is true, what is the simplest way to get the >>>information for imported things? As I mentioned above, I would prefer >>>not to run the compiler further than the type checking phase, since >>>otherwise it gets too expensive for IDE usage. Right now HLS uses the >>>information from the .hie files. >>> > >>> > >>> > In fact, this goes into the more general question of how to show >>>information from different analyses within the IDE; I guess solving >>>the case for strictness/analysis may open the door to more (maybe >>>everything recorded inside a `Id`?) >>> > >>> > Regards, >>> > Alejandro >>> > _______________________________________________ >>> > ghc-devs mailing list >>> >ghc-devs at haskell.org >>> >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>_______________________________________________ >>>ghc-devs mailing list >>>ghc-devs at haskell.org >>>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Fri Jan 14 09:23:01 2022 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 14 Jan 2022 01:23:01 -0800 Subject: Strictness/demand info for a Name In-Reply-To: References: Message-ID: Nice, so only I get the corresponding IdInfo, my work is “done”. But I’m still missing how to thread everything together. Right now, what I have to work with are: - The HieAst node I am searching information about, from which I can get the name, - The result of the parsing, renaming, and type checking phases. Is there a way, with that information only, to obtain the corresponding IdInfo? (This might be a very simple question, or just have a negative answer, but I’m not versed at all in how all this information flows within GHC). Thanks in advance, Alejandro El 13 ene 2022 16:50:01, Sebastian Graf escribió: > Yes, every imported identifier from a module that was compiled with > optimisations should have the proper analysis information in its IdInfo. > So if you have `base` somewhere in one of your compiled libraries and load > it, then the identifier of `GHC.OldList.map` will have an `idDmdSig` that > says it's strict in the list parameter. > > At least that's how it works in GHC, where these IdInfos are populated > with the information from the loaded interface files. The situation with > HLS might be different, although I wouldn't expect that. > > ------ Originalnachricht ------ > Von: "Alejandro Serrano Mena" > An: "Sebastian Graf" > Cc: "GHC developers" ; "Matthew Pickering" < > matthewtpickering at gmail.com> > Gesendet: 13.01.2022 16:43:50 > Betreff: Re: Re[2]: Strictness/demand info for a Name > > Thanks for the pointers! :) > > Knowing this, let me maybe rephrase my question: is it possible to get > demand information of identifiers *without* running the analysis itself? > > Alejandro > > El 13 ene 2022 15:45:29, Sebastian Graf escribió: > >> Yes, Matt is right. >> >> `dmdSigInfo` describes the how a function Id uses its arguments and free >> variables, whereas >> `demandInfo` describes how a (local, mostly) Id is used. >> >> Note that if you wanted to go beyond type-checking, you could probably >> run the analysis on the desugaring of the current module quite easily. >> But the results would be misleading, as prior optimisations (that you >> probably don't want to run) may arrange the program in a way that demand >> analysis has an easier time. >> >> ------ Originalnachricht ------ >> Von: "Matthew Pickering" >> An: "Alejandro Serrano Mena" >> Cc: "GHC developers" >> Gesendet: 13.01.2022 15:38:29 >> Betreff: Re: Strictness/demand info for a Name >> >> You look at `dmdSigInfo` in `IdInfo`. >> >> >> Matt >> >> >> On Thu, Jan 13, 2022 at 2:20 PM Alejandro Serrano Mena >> >> wrote: >> >> > >> >> > Dear all, >> >> > >> >> > I’m trying to bring the information about demand and strictness to the >> Haskell Language Server, but I cannot find a way to do so. I was wondering >> whether you could help me :) >> >> > >> >> > Here’s my understanding; please correct me if I’m wrong: >> >> > >> >> > The analysis runs on Core, so getting this information for the current >> file would require to run the compiler further than type checking, which is >> quite expensive, >> >> > However, this analysis should somehow use known information about >> imported functions, which should be readily available somewhere, >> >> > If the above is true, what is the simplest way to get the information >> for imported things? As I mentioned above, I would prefer not to run the >> compiler further than the type checking phase, since otherwise it gets too >> expensive for IDE usage. Right now HLS uses the information from the .hie >> files. >> >> > >> >> > >> >> > In fact, this goes into the more general question of how to show >> information from different analyses within the IDE; I guess solving the >> case for strictness/analysis may open the door to more (maybe everything >> recorded inside a `Id`?) >> >> > >> >> > Regards, >> >> > Alejandro >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> >ghc-devs at haskell.org >> >> >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Fri Jan 14 09:28:40 2022 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 14 Jan 2022 14:58:40 +0530 Subject: Strictness/demand info for a Name In-Reply-To: References: Message-ID: <20220114092840.igtlw4ccvnjkcguq@zubin-msi> See https://hackage.haskell.org/package/ghc-9.2.1/docs/GHC-Driver-Env.html#v:lookupType On 22/01/14 01:23, Alejandro Serrano Mena wrote: >Nice, so only I get the corresponding IdInfo, my work is “done”. But I’m >still missing how to thread everything together. Right now, what I have to >work with are: > > - The HieAst node I am searching information about, from which I can get > the name, > - The result of the parsing, renaming, and type checking phases. > >Is there a way, with that information only, to obtain the corresponding >IdInfo? (This might be a very simple question, or just have a negative >answer, but I’m not versed at all in how all this information flows within >GHC). > >Thanks in advance, >Alejandro > >El 13 ene 2022 16:50:01, Sebastian Graf escribió: > >> Yes, every imported identifier from a module that was compiled with >> optimisations should have the proper analysis information in its IdInfo. >> So if you have `base` somewhere in one of your compiled libraries and load >> it, then the identifier of `GHC.OldList.map` will have an `idDmdSig` that >> says it's strict in the list parameter. >> >> At least that's how it works in GHC, where these IdInfos are populated >> with the information from the loaded interface files. The situation with >> HLS might be different, although I wouldn't expect that. >> >> ------ Originalnachricht ------ >> Von: "Alejandro Serrano Mena" >> An: "Sebastian Graf" >> Cc: "GHC developers" ; "Matthew Pickering" < >> matthewtpickering at gmail.com> >> Gesendet: 13.01.2022 16:43:50 >> Betreff: Re: Re[2]: Strictness/demand info for a Name >> >> Thanks for the pointers! :) >> >> Knowing this, let me maybe rephrase my question: is it possible to get >> demand information of identifiers *without* running the analysis itself? >> >> Alejandro >> >> El 13 ene 2022 15:45:29, Sebastian Graf escribió: >> >>> Yes, Matt is right. >>> >>> `dmdSigInfo` describes the how a function Id uses its arguments and free >>> variables, whereas >>> `demandInfo` describes how a (local, mostly) Id is used. >>> >>> Note that if you wanted to go beyond type-checking, you could probably >>> run the analysis on the desugaring of the current module quite easily. >>> But the results would be misleading, as prior optimisations (that you >>> probably don't want to run) may arrange the program in a way that demand >>> analysis has an easier time. >>> >>> ------ Originalnachricht ------ >>> Von: "Matthew Pickering" >>> An: "Alejandro Serrano Mena" >>> Cc: "GHC developers" >>> Gesendet: 13.01.2022 15:38:29 >>> Betreff: Re: Strictness/demand info for a Name >>> >>> You look at `dmdSigInfo` in `IdInfo`. >>> >>> >>> Matt >>> >>> >>> On Thu, Jan 13, 2022 at 2:20 PM Alejandro Serrano Mena >>> >>> wrote: >>> >>> > >>> >>> > Dear all, >>> >>> > >>> >>> > I’m trying to bring the information about demand and strictness to the >>> Haskell Language Server, but I cannot find a way to do so. I was wondering >>> whether you could help me :) >>> >>> > >>> >>> > Here’s my understanding; please correct me if I’m wrong: >>> >>> > >>> >>> > The analysis runs on Core, so getting this information for the current >>> file would require to run the compiler further than type checking, which is >>> quite expensive, >>> >>> > However, this analysis should somehow use known information about >>> imported functions, which should be readily available somewhere, >>> >>> > If the above is true, what is the simplest way to get the information >>> for imported things? As I mentioned above, I would prefer not to run the >>> compiler further than the type checking phase, since otherwise it gets too >>> expensive for IDE usage. Right now HLS uses the information from the .hie >>> files. >>> >>> > >>> >>> > >>> >>> > In fact, this goes into the more general question of how to show >>> information from different analyses within the IDE; I guess solving the >>> case for strictness/analysis may open the door to more (maybe everything >>> recorded inside a `Id`?) >>> >>> > >>> >>> > Regards, >>> >>> > Alejandro >>> >>> > _______________________________________________ >>> >>> > ghc-devs mailing list >>> >>> >ghc-devs at haskell.org >>> >>> >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> >>> ghc-devs mailing list >>> >>> ghc-devs at haskell.org >>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>> >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From benjamin.redelings at gmail.com Sat Jan 15 19:09:25 2022 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Sat, 15 Jan 2022 11:09:25 -0800 Subject: Question about ambiguous predicates in pattern bindings Message-ID: Hi, 1. I'm reading "A Static semantics for Haskell" and trying to code it up.  I came across some odd behavior with pattern bindings, and I was wondering if someone could explain or point me in the right direction. Suppose you have the declaration     (x,y) = ('a',2) My current code is yielding:     x :: Num a => Char     y :: Num a => a However, I notice that ghci gives x the type Char, with no constraint, which is what I would expect.  It also gives y the type 'Num b => b', so I don't think it is defaulting a to Int here. The weird results from my code stem from rule BIND-PRED in Figure 15 of https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semantics.ps     E  |-  bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, theta => LVE) Here theta = ( Num a ) and LVE = { x :: Char, y :: a }.  So, theta => LVE is     { x :: Num a => Char, y :: Num a => a } The obvious thing to do is avoid changing a type T to Num a => T if T does not contain a.  Also I'm not totally sure if that trick gets to the bottom of the issue.  However, the paper doesn't mention define theta => LVE that way.  Is there something else I should read on this? 2. If we just chop out predicates which mention variables not in the type ( == ambiguous predicates?) then I'm not totally sure how to create code for this. I would imagine that we have something like     tup dn = ('a', fromInteger dn 2)     x = case (tup dn) of (x,y) -> x     y dn case (tup dn) of (x,y) -> y In this case its not clear where to get the `dn` argument of `tup` from, in the definition of `x`.  Can we pass in `undefined`?  Should we do something else? If anyone can shed light on this, I would be grateful :-) -BenRI From benjamin.redelings at gmail.com Tue Jan 18 20:55:39 2022 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Tue, 18 Jan 2022 12:55:39 -0800 Subject: Question about retaining / deferring /defaulting ambiguous predicates (was Question about ambiguous predicates in pattern bindings) In-Reply-To: References: Message-ID: <0251fb0b-b4b2-d91b-ca34-55e3b812e456@gmail.com> Hi, 1. I think I have clarified my problem a bit.  It is actually not related to pattern bindings. Here's an example: h = let f c i = if i > 10 then c else g c 'b' g 'a' w = f 'b' 10 g z w = z in (f 'a' (1::Int), f 'a' (1.0::Double)) If I am understanding the Haskell type system correctly, * the definitions of f and g form a recursive group * the monomorphism restriction is not invoked * the inner binding (to f and g) leads to a local value environment (LVE): { f :: Char -> a -> Char; g :: Char -> Char -> Char } with predicates (Num a, Ord a) 2. In this situation, Typing Haskell in Haskell suggests that we should NOT apply the predicates to the environment because the type for g does not contain 'a', and would become ambiguous (section 11.6.2).  Instead, we should only apply predicates to the environment if their type variables are present in ALL types in the current declaration group. Since the predicates (Num a, and Ord a) are not retained, then we cannot quantify over a. It seems like this should make `f` monomorphic in a, and thus we should not be able apply (f 'a') to both (1::Int) and (1::Double). Does that make any sense? 3. GHC, however, compiles this just fine.  However, if I add "default ()", then it no longer compiles. 4. On further reflection, Typing Haskell in Haskell applies defaulting rules when evaluating each binding, and not just at the top level.  So this might be part of where my code is going wrong. -BenRI On 1/15/22 11:09 AM, Benjamin Redelings wrote: > Hi, > > 1. I'm reading "A Static semantics for Haskell" and trying to code it > up.  I came across some odd behavior with pattern bindings, and I was > wondering if someone could explain or point me in the right direction. > > Suppose you have the declaration > >     (x,y) = ('a',2) > > My current code is yielding: > >     x :: Num a => Char > >     y :: Num a => a > > However, I notice that ghci gives x the type Char, with no constraint, > which is what I would expect.  It also gives y the type 'Num b => b', > so I don't think it is defaulting a to Int here. > > The weird results from my code stem from rule BIND-PRED in Figure 15 > of > https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semantics.ps > >     E  |-  bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, > theta => LVE) > > Here theta = ( Num a ) and LVE = { x :: Char, y :: a }.  So, theta => > LVE is > >     { x :: Num a => Char, y :: Num a => a } > > The obvious thing to do is avoid changing a type T to Num a => T if T > does not contain a.  Also I'm not totally sure if that trick gets to > the bottom of the issue.  However, the paper doesn't mention define > theta => LVE that way.  Is there something else I should read on this? > > 2. If we just chop out predicates which mention variables not in the > type ( == ambiguous predicates?) then I'm not totally sure how to > create code for this. > > I would imagine that we have something like > >     tup dn = ('a', fromInteger dn 2) > >     x = case (tup dn) of (x,y) -> x > >     y dn case (tup dn) of (x,y) -> y > > In this case its not clear where to get the `dn` argument of `tup` > from, in the definition of `x`.  Can we pass in `undefined`? Should we > do something else? > > If anyone can shed light on this, I would be grateful :-) > > -BenRI > -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhpetersen at gmail.com Sun Jan 23 07:30:26 2022 From: juhpetersen at gmail.com (Jens Petersen) Date: Sun, 23 Jan 2022 15:30:26 +0800 Subject: [Haskell] [ANNOUNCE] GHC 9.0.2 released In-Reply-To: <20211225202027.jxlafyybul4bltfb@zubin-msi> References: <20211225202027.jxlafyybul4bltfb@zubin-msi> Message-ID: First of all a big thank you and congratulations on the highly anticipated 9.0.2 release. I have been putting off this mail for a while: I actually built it last month right away in Fedora's new ghc9.0 package (available now for all current Fedora releases). Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to 9.0.2, since nightly-2022-01-10. :-) However two points I wanted to mention: - firstly (minor), the libraries/containers source is not clean (which explains why the tarball is so big) - More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400 I can't really see any good way to resolve this in the short term. Thanks, Jens On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote: > The GHC developers are very happy to at long last announce the > availability of GHC 9.0.2. Binary distributions, source distributions, > and documentation are available at the > [usual place](https://downloads.haskell.org/ghc/9.0.2/). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Jan 23 07:40:05 2022 From: david.feuer at gmail.com (David Feuer) Date: Sun, 23 Jan 2022 02:40:05 -0500 Subject: [Haskell] [ANNOUNCE] GHC 9.0.2 released In-Reply-To: References: <20211225202027.jxlafyybul4bltfb@zubin-msi> Message-ID: Could you explain what you mean about the containers source not being "clean"? On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote: > First of all a big thank you and congratulations on the highly anticipated > 9.0.2 release. > > I have been putting off this mail for a while: > I actually built it last month right away in Fedora's new ghc9.0 package > (available now for all current Fedora releases). > Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to > 9.0.2, since nightly-2022-01-10. :-) > > However two points I wanted to mention: > > - firstly (minor), the libraries/containers source is not clean (which > explains why the tarball is so big) > > > - More serious: why was Win32 major bumped from 2.10 to 2.12? > - this breaks foundation, hence current Stackage Nightly is kind of > broken for Windows now: > https://github.com/commercialhaskell/stackage/issues/6400 > > I can't really see any good way to resolve this in the short term. > > Thanks, Jens > > > On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote: > >> The GHC developers are very happy to at long last announce the >> availability of GHC 9.0.2. Binary distributions, source distributions, >> and documentation are available at the >> [usual place](https://downloads.haskell.org/ghc/9.0.2/). >> >> _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Sun Jan 23 08:02:15 2022 From: zubin at well-typed.com (Zubin Duggal) Date: Sun, 23 Jan 2022 13:32:15 +0530 Subject: [Haskell] [ANNOUNCE] GHC 9.0.2 released In-Reply-To: References: <20211225202027.jxlafyybul4bltfb@zubin-msi> Message-ID: <20220123080215.b4bvjuxkvw5miohb@zubin-msi> > - More serious: why was Win32 major bumped from 2.10 to 2.12? > - this breaks foundation, hence current Stackage Nightly is kind of > broken for Windows now: > https://github.com/commercialhaskell/stackage/issues/6400 We needed to bump Win32 as per a request from the maintainer made at https://gitlab.haskell.org/ghc/ghc/-/issues/20017 Bumping it from 2.10.0 to 2.10.1.0 ran into https://github.com/haskell/win32/issues/174, which was fixed by https://github.com/haskell/win32/pull/175 Given this, our options at the time were: 1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32 2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10, which is what caused WinIO/#174 3) Use Win32 2.12.0.1, which contains the requested fix(ghc/#20017), as well as the explicit exports added by #175, along with a few other minor changes from Win32 2.11 which I don't think are responsible for any of the pain discussed in the stackage issue. I made the decision to go with option 3 in the interests of getting the release out. However, if I understand correctly, we would still end up with the same problems as brought up in the stackage issue if we went with option 1. We might have avoided some of this pain if we went with option 2 and reverted the offending commits from WinIO 2.10 instead of using explicit import lists. But removing features from a major release of a library didn't seem like a good idea at a time, and would have delayed the 9.0.2 release even more. I hope this makes the reasoning for the decision clearer, and I do apologise for any pain caused. I did believe that under the circumstances bumping WinIO to 2.12.0.1 was the best way forward. Perhaps option 2 would have been better in retrospect, but at the time the benefits for such a change (in particular the regression in functionality) in a major release of Win32 were not so clear. Cheers, Zubin From zubin at well-typed.com Sun Jan 23 08:07:26 2022 From: zubin at well-typed.com (Zubin) Date: Sun, 23 Jan 2022 13:37:26 +0530 Subject: [Haskell] [ANNOUNCE] GHC 9.0.2 released In-Reply-To: <20220123080215.b4bvjuxkvw5miohb@zubin-msi> References: <20211225202027.jxlafyybul4bltfb@zubin-msi> <20220123080215.b4bvjuxkvw5miohb@zubin-msi> Message-ID: <283FB15D-E3DE-49FE-B7DF-986D66D04F38@well-typed.com> I wrote WinIO a couple of times when I meant to type Win32. Sorry! On 23 January 2022 1:32:15 pm IST, Zubin Duggal wrote: > >> - More serious: why was Win32 major bumped from 2.10 to 2.12? >> - this breaks foundation, hence current Stackage Nightly is kind of >> broken for Windows now: >> https://github.com/commercialhaskell/stackage/issues/6400 > >We needed to bump Win32 as per a request from the maintainer made at >https://gitlab.haskell.org/ghc/ghc/-/issues/20017 > >Bumping it from 2.10.0 to 2.10.1.0 ran into >https://github.com/haskell/win32/issues/174, which was fixed by >https://github.com/haskell/win32/pull/175 > >Given this, our options at the time were: > >1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32 > >2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10, > which is what caused WinIO/#174 > >3) Use Win32 2.12.0.1, which contains the requested fix(ghc/#20017), as > well as the explicit exports added by #175, along with a few other minor > changes from Win32 2.11 which I don't think are responsible for any of > the pain discussed in the stackage issue. > >I made the decision to go with option 3 in the interests of getting the >release out. > >However, if I understand correctly, we would still end up with the same >problems as brought up in the stackage issue if we went with option 1. > >We might have avoided some of this pain if we went with option 2 and >reverted the offending commits from WinIO 2.10 instead of using explicit >import lists. But removing features from a major release of a library >didn't seem like a good idea at a time, and would have delayed the 9.0.2 >release even more. > >I hope this makes the reasoning for the decision clearer, and I >do apologise for any pain caused. I did believe that under the >circumstances bumping WinIO to 2.12.0.1 was the best way forward. >Perhaps option 2 would have been better in retrospect, but at the >time the benefits for such a change (in particular the regression in >functionality) in a major release of Win32 were not so clear. > >Cheers, >Zubin >_______________________________________________ >Glasgow-haskell-users mailing list >Glasgow-haskell-users at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users From juhpetersen at gmail.com Sun Jan 23 09:12:57 2022 From: juhpetersen at gmail.com (Jens Petersen) Date: Sun, 23 Jan 2022 17:12:57 +0800 Subject: [Haskell] [ANNOUNCE] GHC 9.0.2 released In-Reply-To: References: <20211225202027.jxlafyybul4bltfb@zubin-msi> Message-ID: On Sun, 23 Jan 2022 at 15:40, David Feuer wrote: > Could you explain what you mean about the containers source not being > "clean"? > I forgot to say "in the source tarball" explicitly. If you look in libraries/containers/containers/dist-install, you can see what I am talking about. (I first discovered this because it broke the Fedora build - so I just remove it before building.) Jens On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote: > >> First of all a big thank you and congratulations on the highly >> anticipated 9.0.2 release. >> >> I have been putting off this mail for a while: >> I actually built it last month right away in Fedora's new ghc9.0 package >> (available now for all current Fedora releases). >> Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to >> 9.0.2, since nightly-2022-01-10. :-) >> >> However two points I wanted to mention: >> >> - firstly (minor), the libraries/containers source is not clean >> (which explains why the tarball is so big) >> >> >> - More serious: why was Win32 major bumped from 2.10 to 2.12? >> - this breaks foundation, hence current Stackage Nightly is kind >> of broken for Windows now: >> https://github.com/commercialhaskell/stackage/issues/6400 >> >> I can't really see any good way to resolve this in the short term. >> >> Thanks, Jens >> >> >> On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote: >> >>> The GHC developers are very happy to at long last announce the >>> availability of GHC 9.0.2. Binary distributions, source distributions, >>> and documentation are available at the >>> [usual place](https://downloads.haskell.org/ghc/9.0.2/). >>> >>> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Jan 23 13:45:38 2022 From: david.feuer at gmail.com (David Feuer) Date: Sun, 23 Jan 2022 08:45:38 -0500 Subject: [Haskell] [ANNOUNCE] GHC 9.0.2 released In-Reply-To: References: <20211225202027.jxlafyybul4bltfb@zubin-msi> Message-ID: There's no such directory in the Hackage or GitHub source. I guess it must have crept in on the GHC side? On Sun, Jan 23, 2022, 4:13 AM Jens Petersen wrote: > On Sun, 23 Jan 2022 at 15:40, David Feuer wrote: > >> Could you explain what you mean about the containers source not being >> "clean"? >> > > I forgot to say "in the source tarball" explicitly. > If you look in libraries/containers/containers/dist-install, you can see > what I am talking about. > (I first discovered this because it broke the Fedora build - so I just > remove it before building.) > > Jens > > On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote: >> >>> First of all a big thank you and congratulations on the highly >>> anticipated 9.0.2 release. >>> >>> I have been putting off this mail for a while: >>> I actually built it last month right away in Fedora's new ghc9.0 package >>> (available now for all current Fedora releases). >>> Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to >>> 9.0.2, since nightly-2022-01-10. :-) >>> >>> However two points I wanted to mention: >>> >>> - firstly (minor), the libraries/containers source is not clean >>> (which explains why the tarball is so big) >>> >>> >>> - More serious: why was Win32 major bumped from 2.10 to 2.12? >>> - this breaks foundation, hence current Stackage Nightly is kind >>> of broken for Windows now: >>> https://github.com/commercialhaskell/stackage/issues/6400 >>> >>> I can't really see any good way to resolve this in the short term. >>> >>> Thanks, Jens >>> >>> >>> On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote: >>> >>>> The GHC developers are very happy to at long last announce the >>>> availability of GHC 9.0.2. Binary distributions, source distributions, >>>> and documentation are available at the >>>> [usual place](https://downloads.haskell.org/ghc/9.0.2/). >>>> >>>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From nr at cs.tufts.edu Sun Jan 23 15:00:52 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Sun, 23 Jan 2022 10:00:52 -0500 Subject: any luck using "retrie" refactoring tool on GHC sources? Message-ID: <20220123150052.378F52C2CEF@homedog.cs.tufts.edu> I'm trying to use the retrie refactoring tool, but I'm getting a mysterious error message: nr at homedog ~/a/g/compiler [1]> retrie --adhoc "forall x . not (backendNeedn'tLink x) == backendNeedsLink x" parseAdhocs:1:80: error: parse error on input ‘#-}’ retrie: user error (parse failed) The Tool was installed using cabal install; its github page is https://github.com/facebookincubator/retrie/#readme. Has anybody had any success using this tool on the GHC sources? I'd love a workaround, or just advice. Norman From david.feuer at gmail.com Sun Jan 23 19:07:27 2022 From: david.feuer at gmail.com (David Feuer) Date: Sun, 23 Jan 2022 14:07:27 -0500 Subject: Not all splices are the same Message-ID: I've been a bit upset by the challenges Template Haskell poses for type inference. For example, (3 :: Int) == $$(...) may typecheck when $$(...) == (3 :: Int) does not. I don't imagine this problem can be solved in general, but I'm rather curious whether it might be possible to solve for "pure" splices, with types that look like forall m. Quote m => Code m a Would it be possible to get full bidirectional inference for these if they were somehow marked specially by the user? For instance, if I wrote $$$e that could mean e should be interpreted as having some type PCode a where newtype PCode a = PCode (forall m. Quote m => a) -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthewtpickering at gmail.com Sun Jan 23 22:30:33 2022 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Sun, 23 Jan 2022 22:30:33 +0000 Subject: Not all splices are the same In-Reply-To: References: Message-ID: Seems related to https://gitlab.haskell.org/ghc/ghc/-/issues/18211 There is also a small section in my thesis (4.1.2) which explains why changing the implementation of typed quotations would allow this program to be accepted. Matt On Sun, Jan 23, 2022 at 7:08 PM David Feuer wrote: > > I've been a bit upset by the challenges Template Haskell poses for type inference. For example, > > (3 :: Int) == $$(...) > > may typecheck when > > $$(...) == (3 :: Int) > > does not. I don't imagine this problem can be solved in general, but I'm rather curious whether it might be possible to solve for "pure" splices, with types that look like > > forall m. Quote m => Code m a > > Would it be possible to get full bidirectional inference for these if they were somehow marked specially by the user? For instance, if I wrote > > $$$e > > that could mean e should be interpreted as having some type > > PCode a > > where > > newtype PCode a = PCode (forall m. Quote m => a) > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at smart-cactus.org Mon Jan 24 14:23:26 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 24 Jan 2022 09:23:26 -0500 Subject: any luck using "retrie" refactoring tool on GHC sources? In-Reply-To: <20220123150052.378F52C2CEF@homedog.cs.tufts.edu> References: <20220123150052.378F52C2CEF@homedog.cs.tufts.edu> Message-ID: <8735ldp60m.fsf@smart-cactus.org> Norman Ramsey writes: > I'm trying to use the retrie refactoring tool, but I'm getting a > mysterious error message: > > nr at homedog ~/a/g/compiler [1]> retrie --adhoc "forall x . not (backendNeedn'tLink x) == backendNeedsLink x" > > parseAdhocs:1:80: error: parse error on input ‘#-}’ > retrie: user error (parse failed) > > The Tool was installed using cabal install; its github page is > https://github.com/facebookincubator/retrie/#readme. > > Has anybody had any success using this tool on the GHC sources? > I'd love a workaround, or just advice. > For what it's worth, Norman has reported this issue upstream as https://github.com/facebookincubator/retrie/issues/41 Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From nr at cs.tufts.edu Mon Jan 24 21:46:31 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Mon, 24 Jan 2022 16:46:31 -0500 Subject: any luck using "retrie" refactoring tool on GHC sources? In-Reply-To: <8735ldp60m.fsf@smart-cactus.org> (sfid-H-20220124-092824-+55.11-1@multi.osbf.lua) References: <20220123150052.378F52C2CEF@homedog.cs.tufts.edu> <8735ldp60m.fsf@smart-cactus.org> (sfid-H-20220124-092824-+55.11-1@multi.osbf.lua) Message-ID: <20220124214631.8FCF32C2E77@homedog.cs.tufts.edu> > > I'm trying to use the retrie refactoring tool.. > > > For what it's worth, Norman has reported this issue upstream as > https://github.com/facebookincubator/retrie/issues/41 Turns out the tool wants `=` in the rule, not `==`. And if you have a ' in your function name, the tool barfs because it launches a `grep` command without escaping the ' properly to the shell. I have pushed a fix at https://github.com/facebookincubator/retrie/pull/43. Norman From nr at cs.tufts.edu Mon Jan 24 22:02:05 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Mon, 24 Jan 2022 17:02:05 -0500 Subject: use Hadrian to see if compiler compiles? Message-ID: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> I'm currently doing some refactoring of the GHC sources, which involves moving definitions between modules. As a sanity check I want to compile often, so if I've broken anything (or have inadvertently created circular imports) I can find out quickly. I'm currently using ./hadrian/build -j but I really don't need to build libraries or a stage 2 compiler. I tried looking over `./hadrian/build --help`, but I'm not confident that I understand what's there. My best guess is ./hadrian/build -j stage0:lib:ghc Would that accomplish my goal? Norman From lists at richarde.dev Mon Jan 24 22:28:32 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 24 Jan 2022 22:28:32 +0000 Subject: use Hadrian to see if compiler compiles? In-Reply-To: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> Message-ID: <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> My recommendation: ./hadrian/ghci. The first time you run it, it may spin for a little while, but it will eventually deliver you to a GHCi prompt, with all of GHC loaded. (You can e.g. `:type splitTyConApp_maybe`, after `import GHC.Core.Type`.) At that point, :reload will be your dear friend. That's what I do when I'm doing e.g. module reorganization and care much more about "does it compile" than "does it work". Richard > On Jan 24, 2022, at 5:02 PM, Norman Ramsey wrote: > > I'm currently doing some refactoring of the GHC sources, which > involves moving definitions between modules. As a sanity check > I want to compile often, so if I've broken anything (or have inadvertently > created circular imports) I can find out quickly. I'm currently using > > ./hadrian/build -j > > but I really don't need to build libraries or a stage 2 compiler. > I tried looking over `./hadrian/build --help`, but I'm not confident > that I understand what's there. My best guess is > > ./hadrian/build -j stage0:lib:ghc > > Would that accomplish my goal? > > > Norman > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From nr at cs.tufts.edu Tue Jan 25 19:15:49 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Tue, 25 Jan 2022 14:15:49 -0500 Subject: use Hadrian to see if compiler compiles? In-Reply-To: <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> (sfid-H-20220124-172904-+77.85-1@multi.osbf.lua) References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> (sfid-H-20220124-172904-+77.85-1@multi.osbf.lua) Message-ID: <20220125191549.96D382C2799@homedog.cs.tufts.edu> > My recommendation: ./hadrian/ghci. The first time you run it, it may spin > for a little while, but it will eventually deliver you to a GHCi prompt, > with all of GHC loaded. (You can e.g. `:type splitTyConApp_maybe`, after > `import GHC.Core.Type`.) At that point, :reload will be your dear friend. > That's what I do when I'm doing e.g. module reorganization and care much > more about "does it compile" than "does it work". Cool! Supposing I wanted to run just a little code that uses the GHC API. Would there be a way to load the Prelude and similar things into that GHCi, so it could know about Bool and IO and such things? Norman From lists at richarde.dev Tue Jan 25 19:21:37 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 25 Jan 2022 19:21:37 +0000 Subject: use Hadrian to see if compiler compiles? In-Reply-To: <20220125191549.96D382C2799@homedog.cs.tufts.edu> References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220125191549.96D382C2799@homedog.cs.tufts.edu> Message-ID: <010f017e92afb9b7-962cad9a-43c5-4d8b-abb6-c2d8d8d4f769-000000@us-east-2.amazonses.com> > On Jan 25, 2022, at 2:15 PM, Norman Ramsey wrote: > > Cool! Supposing I wanted to run just a little code that uses the GHC API. > Would there be a way to load the Prelude and similar things into that GHCi, > so it could know about Bool and IO and such things? The GHCi that runs is your system's GHCi, so it has access to everything installed in your bootstrap GHC. However, I don't see a connection between your second sentence and your last sentence: that is, the GHCi will certainly know about Bool and IO, but I don't see how that helps with the GHC API. I have no idea how you would use the GHC API in this mode. My advice would be to use this trick to get quick feedback about compilation, and then once GHC compiles, use other more well-worn techniques to build it and test your application. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From harendra.kumar at gmail.com Wed Jan 26 13:08:18 2022 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Wed, 26 Jan 2022 18:38:18 +0530 Subject: downloading ghc head version Message-ID: Hi, I am trying to set up a CI for ghc head version. I am not sure what is the official supported method to install a nightly/head version of GHC. haskell/actions/setup on github seems to support it via ghcup. But it almost always fails, I saw it succeeding once till now. It tries to download it from the following URL, but fails with 404 not found: downloading: https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb9-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb9-integer-simple I tried this link in the browser and I get the same error. Is that the right way to install it? If not, can someone suggest a reliable way to get the head version, other than building it myself? Thanks, Harendra From nr at cs.tufts.edu Wed Jan 26 16:31:54 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Wed, 26 Jan 2022 11:31:54 -0500 Subject: Curiosity: What accounts for the growth in the RTS in 9.2? Message-ID: <20220126163154.C54822C272C@homedog.cs.tufts.edu> I was chatting with a colleague who asked "How big is GHC's run-time system." In the spirit of "look and find out," I found this: nr at homedog ~/.ghcup> ls -hl **HSrts.a -rw-r--r-- 1 nr nr 8.7M Sep 27 16:13 ghc/8.10.7/lib/ghc-8.10.7/rts/libHSrts.a -rw-r--r-- 1 nr nr 8.8M Sep 27 16:36 ghc/9.0.1/lib/ghc-9.0.1/rts/libHSrts.a -rw-r--r-- 1 nr nr 11M Jan 24 15:06 ghc/9.2.1/lib/ghc-9.2.1/rts/libHSrts.a All these binaries were installed by ghcup using the default settings. Does anybody know what accounts for the big jump from 9.0 to 9.2? Norman From lists at richarde.dev Wed Jan 26 16:57:42 2022 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 26 Jan 2022 16:57:42 +0000 Subject: Question about ambiguous predicates in pattern bindings In-Reply-To: References: Message-ID: <010f017e9752536d-cf29ad4c-93e6-4f99-98a9-a5a700240d05-000000@us-east-2.amazonses.com> I've been a bit under water of late, so I haven't gotten to respond to this. But is this superseded by your later email? If not, I'm happy to take a stab at an answer. Thanks, Richard > On Jan 15, 2022, at 2:09 PM, Benjamin Redelings wrote: > > Hi, > > 1. I'm reading "A Static semantics for Haskell" and trying to code it up. I came across some odd behavior with pattern bindings, and I was wondering if someone could explain or point me in the right direction. > > Suppose you have the declaration > > (x,y) = ('a',2) > > My current code is yielding: > > x :: Num a => Char > > y :: Num a => a > > However, I notice that ghci gives x the type Char, with no constraint, which is what I would expect. It also gives y the type 'Num b => b', so I don't think it is defaulting a to Int here. > > The weird results from my code stem from rule BIND-PRED in Figure 15 of https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semantics.ps > > E |- bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, theta => LVE) > > Here theta = ( Num a ) and LVE = { x :: Char, y :: a }. So, theta => LVE is > > { x :: Num a => Char, y :: Num a => a } > > The obvious thing to do is avoid changing a type T to Num a => T if T does not contain a. Also I'm not totally sure if that trick gets to the bottom of the issue. However, the paper doesn't mention define theta => LVE that way. Is there something else I should read on this? > > 2. If we just chop out predicates which mention variables not in the type ( == ambiguous predicates?) then I'm not totally sure how to create code for this. > > I would imagine that we have something like > > tup dn = ('a', fromInteger dn 2) > > x = case (tup dn) of (x,y) -> x > > y dn case (tup dn) of (x,y) -> y > > In this case its not clear where to get the `dn` argument of `tup` from, in the definition of `x`. Can we pass in `undefined`? Should we do something else? > > If anyone can shed light on this, I would be grateful :-) > > -BenRI > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From nr at cs.tufts.edu Thu Jan 27 19:50:45 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Thu, 27 Jan 2022 14:50:45 -0500 Subject: trouble with formatted Haddock documentation for new module Message-ID: <20220127195045.47B3D2C274B@homedog.cs.tufts.edu> In a new module I'm writing for GHC, I define a record type that has a ton of named fields. Two of the fields have rather large types. Unfortunately, at least with default settings, the Haddock documentation that is well-nigh unreadable (image attached). Does anyone have a workaround? Hécate? (If it's useful, a draft of the offending module can be found at https://gitlab.haskell.org/ghc/ghc/-/blob/wip/backend-as-record/compiler/GHC/Driver/Backend/Record.hs.) Norman -------------- next part -------------- A non-text attachment was scrubbed... Name: h.png Type: image/png Size: 505961 bytes Desc: not available URL: From simon.jakobi at googlemail.com Thu Jan 27 20:07:06 2022 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Thu, 27 Jan 2022 21:07:06 +0100 Subject: trouble with formatted Haddock documentation for new module In-Reply-To: <20220127195045.47B3D2C274B@homedog.cs.tufts.edu> References: <20220127195045.47B3D2C274B@homedog.cs.tufts.edu> Message-ID: Hi Norman, https://github.com/haskell/haddock/issues/472 is a long-standing, related issue. Unfortunately I'm not aware of any workarounds. Simon Am Do., 27. Jan. 2022 um 20:51 Uhr schrieb Norman Ramsey : > > In a new module I'm writing for GHC, I define a record type that has a > ton of named fields. Two of the fields have rather large types. > Unfortunately, at least with default settings, the Haddock > documentation that is well-nigh unreadable (image attached). Does > anyone have a workaround? Hécate? > > (If it's useful, a draft of the offending module can be found at > https://gitlab.haskell.org/ghc/ghc/-/blob/wip/backend-as-record/compiler/GHC/Driver/Backend/Record.hs.) > > > Norman > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From nr at cs.tufts.edu Fri Jan 28 15:30:48 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 28 Jan 2022 10:30:48 -0500 Subject: meaning of title of merge request on gitlab? Message-ID: <20220128153048.3CE6C2C2670@homedog.cs.tufts.edu> I've opened a very, very preliminary MR. The Commentary instructs me to tag it "WIP: ", but gitlab seems to suggest that in order to prevent it from being merged, I need "Draft: <title>". When a merge request is both WIP and Draft, how should it be titled? (The MR in question is https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7442) Norman From sam.derbyshire at gmail.com Fri Jan 28 15:36:29 2022 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Fri, 28 Jan 2022 16:36:29 +0100 Subject: meaning of title of merge request on gitlab? In-Reply-To: <20220128153048.3CE6C2C2670@homedog.cs.tufts.edu> References: <20220128153048.3CE6C2C2670@homedog.cs.tufts.edu> Message-ID: <CAA1CnJNbPNf3z_ZDX09OWjEJjrfRHrWgdfdkEYu352UMdO2Tzg@mail.gmail.com> As far as I understand, WIP and Draft are equivalent. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220128/98565fe6/attachment.html> From shayne.fletcher.50 at gmail.com Fri Jan 28 15:59:13 2022 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Fri, 28 Jan 2022 10:59:13 -0500 Subject: 9.2.2 release schedule? In-Reply-To: <87lf097t3u.fsf@smart-cactus.org> References: <CAMsAzy-TYfRQ97hGk1vqhr_YbyZVBDFUhk4ha8B3qHSvsCUEVw@mail.gmail.com> <87lf097t3u.fsf@smart-cactus.org> Message-ID: <CAMsAzy-6QkutffX9kPLG1kDuczMs38JG-HGSCiBu7YZbt7DmFg@mail.gmail.com> On Fri, Dec 24, 2021 at 1:31 PM Ben Gamari <ben at well-typed.com> wrote: > Shayne Fletcher <shayne.fletcher.50 at gmail.com> writes: > > > Anyone know of any scheduling plans for ghc-9.2.2? > > > It should be out by mid-January. There are quite a few > backports that we need to push through and the focus recently has been > on finalizing 9.0.2 but I'll be turning my attention to 9.2.2 after I > the holiday. > > g'day again ben :) what's the latest? -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220128/618d0ecb/attachment.html> From nr at cs.tufts.edu Fri Jan 28 16:52:00 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 28 Jan 2022 11:52:00 -0500 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> (sfid-H-20220124-172904-+77.85-1@multi.osbf.lua) References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <sfid-H-20220124-172904-+77.85-1@multi.osbf.lua> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> (sfid-H-20220124-172904-+77.85-1@multi.osbf.lua) Message-ID: <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> > My recommendation: ./hadrian/ghci. Richard, this suggestion has been so useful that I would like to follow it up. I'm about to change a type definition. This change may wreak havoc in many parts of GHC, and this is exactly what I want: I'm looking for type-error messages that will tell me what code I need to fix. I do this work in emacs using `M-x compile` and `next-error`. The key property is that `next-error` requires just a couple of keystrokes (C-x `) and it makes Emacs take me to the relevant source-code location quickly. But telling `M-x compile` to run `./hadrian/build` is quite slow. Is there a way to leverage `./hadrian/ghci` for this workflow? Norman From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Fri Jan 28 17:00:29 2022 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 28 Jan 2022 17:00:29 +0000 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <sfid-H-20220124-172904-+77.85-1@multi.osbf.lua> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> Message-ID: <YfQhLXbJ3qDqz9+D@cloudinit-builder> On Fri, Jan 28, 2022 at 11:52:00AM -0500, Norman Ramsey wrote: > > My recommendation: ./hadrian/ghci. > > I'm about to change a type definition. This change may wreak havoc in > many parts of GHC, and this is exactly what I want: I'm looking for > type-error messages that will tell me what code I need to fix. > I do this work in emacs using `M-x compile` and `next-error`. The key > property is that `next-error` requires just a couple of keystrokes > (C-x `) and it makes Emacs take me to the relevant source-code > location quickly. > > But telling `M-x compile` to run `./hadrian/build` is quite slow. Is > there a way to leverage `./hadrian/ghci` for this workflow? Are you familiar with dante-mode for Emacs? It relies on ghci behind the scenes to point out type errors in Emacs Haskell buffers. You might find it convenient even if only for this single-purpose use case. I wrote up how I use dante: http://h2.jaguarpaw.co.uk/posts/how-i-use-dante/ You will have to `M-x customize-group dante` to set the GHCi path to `.../hadrian/ghci`. Tom From sgraf1337 at gmail.com Fri Jan 28 18:02:04 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Fri, 28 Jan 2022 18:02:04 +0000 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <sfid-H-20220124-172904-+77.85-1@multi.osbf.lua> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> Message-ID: <emcdd502a5-5799-49b5-80a7-f2df4f72de08@sebastian-pc> This is the typical use case for a language server. I have haskell-language-server installed and use it extensively on GHC for stuff like jump to definition and immediate compilation feedback. There's also "jump to next error" if you want that. Installation was pretty trivial for me, just flipping this switch in my local ghc.nix clone: https://github.com/alpmestan/ghc.nix/blob/88acad6229300d8917ad226a64de80aa491ffa07/default.nix#L19 You will probably have to install an LSP plugin for emacs first. The hour or so I invested on initial setup has probably saved me several days already. Sebastian ------ Originalnachricht ------ Von: "Norman Ramsey" <nr at cs.tufts.edu> An: ghc-devs at haskell.org Gesendet: 28.01.2022 17:52:00 Betreff: How to exploit ./hadrian/ghci to find errors quickly? > > My recommendation: ./hadrian/ghci. > >Richard, this suggestion has been so useful that I would like to >follow it up. > >I'm about to change a type definition. This change may wreak havoc in >many parts of GHC, and this is exactly what I want: I'm looking for >type-error messages that will tell me what code I need to fix. >I do this work in emacs using `M-x compile` and `next-error`. The key >property is that `next-error` requires just a couple of keystrokes >(C-x `) and it makes Emacs take me to the relevant source-code >location quickly. > >But telling `M-x compile` to run `./hadrian/build` is quite slow. Is >there a way to leverage `./hadrian/ghci` for this workflow? > > >Norman >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From nr at cs.tufts.edu Fri Jan 28 21:45:14 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 28 Jan 2022 16:45:14 -0500 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: <emcdd502a5-5799-49b5-80a7-f2df4f72de08@sebastian-pc> (sfid-H-20220128-130256-+52.59-1@multi.osbf.lua) References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <sfid-H-20220124-172904-+77.85-1@multi.osbf.lua> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> <sfid-H-20220128-130256-+52.59-1@multi.osbf.lua> <emcdd502a5-5799-49b5-80a7-f2df4f72de08@sebastian-pc> (sfid-H-20220128-130256-+52.59-1@multi.osbf.lua) Message-ID: <20220128214514.83F492C2670@homedog.cs.tufts.edu> > This is the typical use case for a language server. > I have haskell-language-server installed and use it extensively on GHC > for stuff like jump to definition and immediate compilation feedback. I would *love* to be doing this. I have had HLS installed on my machine for months, and have been using with Emacs. But to say I have trouble getting it work as advertised is an understatement. For example, on the module I'm trying to diagnose, I'm getting just one error message, on the first line: Data.Binary.Get.runGet at position 1844: not enough bytes > There's also "jump to next error" if you want that. I can't find it using either "C-h f" or using the list of keybindings at https://emacs-lsp.github.io/lsp-mode/page/keybindings/. I think it might be supported by flycheck, but "C-x `" simply says "No more Flycheck errors." In general, my experience is "sometimes it works and sometimes it doesn't." Even for things as simple as "M-." (find definition). If you know of any resources on using HLS with GHC, I'd love to be directed. For example, when Emacs asks if I really want to watch circa 5,000 directories, do I say "yes"? > The hour or so I invested on initial setup has probably saved me several > days already. I am **so eager** to get there. But definitely not there yet. Norman From sam.derbyshire at gmail.com Fri Jan 28 22:18:15 2022 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Fri, 28 Jan 2022 23:18:15 +0100 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: <20220128214514.83F492C2670@homedog.cs.tufts.edu> References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <sfid-H-20220124-172904-+77.85-1@multi.osbf.lua> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> <sfid-H-20220128-130256-+52.59-1@multi.osbf.lua> <emcdd502a5-5799-49b5-80a7-f2df4f72de08@sebastian-pc> <20220128214514.83F492C2670@homedog.cs.tufts.edu> Message-ID: <CAA1CnJNp3kHJWJmqBs4mbOf29pG0r6ZQcFgYY3LzXySnvHrdBQ@mail.gmail.com> The Binary runGet issue usually means that your build tree is out of date. It's probably worth deleting and building from scratch again. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220128/d09803d6/attachment.html> From nr at cs.tufts.edu Fri Jan 28 23:34:23 2022 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 28 Jan 2022 18:34:23 -0500 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: <CAA1CnJNp3kHJWJmqBs4mbOf29pG0r6ZQcFgYY3LzXySnvHrdBQ@mail.gmail.com> (sfid-H-20220128-171925-+45.52-1@multi.osbf.lua) References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <sfid-H-20220124-172904-+77.85-1@multi.osbf.lua> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> <sfid-H-20220128-130256-+52.59-1@multi.osbf.lua> <emcdd502a5-5799-49b5-80a7-f2df4f72de08@sebastian-pc> <20220128214514.83F492C2670@homedog.cs.tufts.edu> <sfid-H-20220128-171925-+45.52-1@multi.osbf.lua> <CAA1CnJNp3kHJWJmqBs4mbOf29pG0r6ZQcFgYY3LzXySnvHrdBQ@mail.gmail.com> (sfid-H-20220128-171925-+45.52-1@multi.osbf.lua) Message-ID: <20220128233423.6A1182C2670@homedog.cs.tufts.edu> > The Binary runGet issue usually means that your build tree is out of date. > It's probably worth deleting and building from scratch again. Brilliant! Definitely working much better! And @Sebastian I start to see the productivity gains. Remove all redundant imports with one click! Norman From mail at joachim-breitner.de Sat Jan 29 11:36:59 2022 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 29 Jan 2022 12:36:59 +0100 Subject: Request for Nominations to the GHC Steering Committee Message-ID: <e9780b87201cc2ea04c89dc9069c9c54e7b95fb2.camel@joachim-breitner.de> Dear Haskell community, the GHC Steering committee is seeking nominations for at least two new members. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail at joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From sgraf1337 at gmail.com Sat Jan 29 11:46:04 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Sat, 29 Jan 2022 11:46:04 +0000 Subject: How to exploit ./hadrian/ghci to find errors quickly? In-Reply-To: <20220128233423.6A1182C2670@homedog.cs.tufts.edu> References: <20220124220205.D735E2C285E@homedog.cs.tufts.edu> <sfid-H-20220124-172904-+77.85-1@multi.osbf.lua> <010f017e8e34809c-2f18386c-a19e-4550-b06d-290057b41129-000000@us-east-2.amazonses.com> <20220128165200.8E9322C1AEB@homedog.cs.tufts.edu> <sfid-H-20220128-130256-+52.59-1@multi.osbf.lua> <emcdd502a5-5799-49b5-80a7-f2df4f72de08@sebastian-pc> <20220128214514.83F492C2670@homedog.cs.tufts.edu> <sfid-H-20220128-171925-+45.52-1@multi.osbf.lua> <CAA1CnJNp3kHJWJmqBs4mbOf29pG0r6ZQcFgYY3LzXySnvHrdBQ@mail.gmail.com> <20220128233423.6A1182C2670@homedog.cs.tufts.edu> Message-ID: <em30992a69-17d5-4ece-af8e-8ba0b8f666dd@sebastian-pc> Great! Glad I could help. FWIW, if I have strange HLS bugs, I mostly restart it (if it had worked before) or delete .hie-bios, where HLS stores its build results. HLS builds the same stuff as what hadrian/ghci needs to build. The former puts it in .hie-bios, the latter in ... .hadrian-ghci? Not sure. Anyway, if HLS behaves strangely, try deleting its build root. Sebastian ------ Originalnachricht ------ Von: "Norman Ramsey" <nr at cs.tufts.edu> An: "Sam Derbyshire" <sam.derbyshire at gmail.com>; ghc-devs at haskell.org Gesendet: 29.01.2022 00:34:23 Betreff: Re: How to exploit ./hadrian/ghci to find errors quickly? > > The Binary runGet issue usually means that your build tree is out of date. > > It's probably worth deleting and building from scratch again. > >Brilliant! Definitely working much better! > >And @Sebastian I start to see the productivity gains. Remove all >redundant imports with one click! > > >Norman >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From juhpetersen at gmail.com Mon Jan 31 13:44:20 2022 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 31 Jan 2022 21:44:20 +0800 Subject: 9.2.2 release schedule? In-Reply-To: <CAMsAzy-6QkutffX9kPLG1kDuczMs38JG-HGSCiBu7YZbt7DmFg@mail.gmail.com> References: <CAMsAzy-TYfRQ97hGk1vqhr_YbyZVBDFUhk4ha8B3qHSvsCUEVw@mail.gmail.com> <87lf097t3u.fsf@smart-cactus.org> <CAMsAzy-6QkutffX9kPLG1kDuczMs38JG-HGSCiBu7YZbt7DmFg@mail.gmail.com> Message-ID: <CAEDGBq+cmyyVL7G+0SeoLBCBTiHKpU=u2XchXjMFNtBZXyDWtA@mail.gmail.com> On Fri, 28 Jan 2022 at 23:59, Shayne Fletcher <shayne.fletcher.50 at gmail.com> wrote: > On Fri, Dec 24, 2021 at 1:31 PM Ben Gamari <ben at well-typed.com> wrote: > >> Shayne Fletcher <shayne.fletcher.50 at gmail.com> writes: >> >> > Anyone know of any scheduling plans for ghc-9.2.2? >> It should be out by mid-January. There are quite a few >> backports that we need to push through and the focus recently has been >> on finalizing 9.0.2 but I'll be turning my attention to 9.2.2 after I the >> holiday. >> > > g'day again ben :) what's the latest? > There is also the 9.2.2 milestone board https://gitlab.haskell.org/ghc/ghc/-/milestones/373 Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220131/75be48d9/attachment.html> From george.colpitts at gmail.com Mon Jan 31 16:35:18 2022 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 31 Jan 2022 12:35:18 -0400 Subject: 9.2.2 release schedule? In-Reply-To: <CAEDGBq+cmyyVL7G+0SeoLBCBTiHKpU=u2XchXjMFNtBZXyDWtA@mail.gmail.com> References: <CAMsAzy-TYfRQ97hGk1vqhr_YbyZVBDFUhk4ha8B3qHSvsCUEVw@mail.gmail.com> <87lf097t3u.fsf@smart-cactus.org> <CAMsAzy-6QkutffX9kPLG1kDuczMs38JG-HGSCiBu7YZbt7DmFg@mail.gmail.com> <CAEDGBq+cmyyVL7G+0SeoLBCBTiHKpU=u2XchXjMFNtBZXyDWtA@mail.gmail.com> Message-ID: <CAB-d4A5NQphJ6fHoOpMM2c0RhZbvDQf8K-aPv696us-dwvAPdg@mail.gmail.com> On Mon, Jan 31, 2022 at 9:45 AM Jens Petersen <juhpetersen at gmail.com> wrote: > On Fri, 28 Jan 2022 at 23:59, Shayne Fletcher < > shayne.fletcher.50 at gmail.com> wrote: > >> On Fri, Dec 24, 2021 at 1:31 PM Ben Gamari <ben at well-typed.com> wrote: >> >>> Shayne Fletcher <shayne.fletcher.50 at gmail.com> writes: >>> >>> > Anyone know of any scheduling plans for ghc-9.2.2? >>> It should be out by mid-January. There are quite a few >>> backports that we need to push through and the focus recently has been >>> on finalizing 9.0.2 but I'll be turning my attention to 9.2.2 after I >>> the holiday. >>> >> >> g'day again ben :) what's the latest? >> > > There is also the 9.2.2 milestone board > https://gitlab.haskell.org/ghc/ghc/-/milestones/373 > Right, but like most milestones there is no due date there for 9.2.2. It would be great if we could get one there. Similarly for 9.4.1 Cheers George > Jens > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220131/339db1b3/attachment.html> From harendra.kumar at gmail.com Mon Jan 31 22:43:18 2022 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Tue, 1 Feb 2022 04:13:18 +0530 Subject: downloading ghc head version In-Reply-To: <CAPW+kkYCFvgOR0SQoT25ZXo4+63p+cgbESX0R5NH+_SfVtzi+A@mail.gmail.com> References: <CAPW+kkYCFvgOR0SQoT25ZXo4+63p+cgbESX0R5NH+_SfVtzi+A@mail.gmail.com> Message-ID: <CAPW+kkab4P4kZ-xFWONmOS0-Fr2kYO_SLjpOAUfdB1ME-r8EMg@mail.gmail.com> It seems the latest artifacts download link (https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/...) at GHC gitlab is not working. If this is not the right place to ask this, can someone point me to the right place? -harendra On Wed, 26 Jan 2022 at 18:38, Harendra Kumar <harendra.kumar at gmail.com> wrote: > > Hi, > > I am trying to set up a CI for ghc head version. I am not sure what is > the official supported method to install a nightly/head version of > GHC. haskell/actions/setup on github seems to support it via ghcup. > But it almost always fails, I saw it succeeding once till now. It > tries to download it from the following URL, but fails with 404 not > found: > > downloading: https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb9-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb9-integer-simple > > I tried this link in the browser and I get the same error. Is that the > right way to install it? If not, can someone suggest a reliable way to > get the head version, other than building it myself? > > Thanks, > Harendra