From b at chreekat.net Thu Dec 3 15:23:33 2020 From: b at chreekat.net (Bryan Richter) Date: Thu, 3 Dec 2020 17:23:33 +0200 Subject: Use of forall as a sigil In-Reply-To: <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> Message-ID: > How do you feel about > > > f :: forall (a :: Type) -> a > or > > g :: (a :: Type) -> a The former has the same problem as the current syntax. The latter seems better, but then I might be confused again. :) My main concern is with the choice of keyword. With data, instance, class, module, ..., the pattern is clear: name the sort of thing you are introducing. forall, on the other hand, doesn't introduce a "forall". It's making explicit the existing universal quantification. But somewhere, an author decided to reuse the same keyword to herald a type argument. It seems they stopped thinking about the meaning of the word itself, saw that it was syntactically in the right spot, and borrowed it to mean something else. I feel like that borrowing introduced a wart. Consider `forall a -> a -> a`. There's still an implicit universal quantification that is assumed, right? I.e., this type signature would be valid for all types `a` ? But then how do we make that quantification explicit? `forall a. forall a -> a -> a`? But oops, have we now introduced a new type argument? I keep referring to the thing as a "type argument". I know it's hard to introduce a new keyword, but imagine if we had `forall a. typearg a -> a -> a`. It would at least point to its meaning. I guess that's pretty close to your > g :: (a :: Type) -> a which is why I think it seems a bit better. On Fri, Nov 20, 2020 at 10:56 PM Richard Eisenberg wrote: > Hi Bryan, > > Thanks for this longer post -- it's very helpful to see this with fresh > eyes. > > > > On Nov 19, 2020, at 2:18 PM, Bryan Richter wrote: > > > > So correct me if I'm wrong: from an implementation perspective, > > `forall a. a -> Int` is a function of two arguments, one of which can > > be elided, while `forall a -> a -> Int` is a function of two > > arguments, all of which must be provided. > > Yes, that's how I read these. > > > > > If that's right, then it bumps into my intuition, which says that the > > former is a function of only one argument. I never thought of `f @Int` > > as partial function application, for instance. :) Is my intuition > > leading me astray? *Should* I consider both functions as having two > > arguments? If so, is that somehow "mathematically true" (a very > > not-mathematical phrase, haha), or is it just an "implementation > > detail"? > > I don't think there's one right answer here. And I'm not quite sure how to > interpret "mathematically true". The best I can get is that, if we consider > System F (a direct inspiration for Haskell's type system), then both > functions really do take 2 arguments (as they do in GHC Core). > > > > > > > So that's one avenue of query I have, but it's actually not the one I > > started off with. Focusing on the simpler case of `forall a -> a`, > > which is a function of one argument, I take issue with how the > > quantification is packed into the syntax for the argument, itself. > > I.e., my intuition tells me this function is valid for all types, > > takes the name of a type as an argument, and returns a value of that > > type, which is three distinct pieces of information. I'd expect a > > syntax like `forall a. elem x a. a -> x`, or maybe `forall a. nameof a > > -> a`. The packing and punning conspire to make the syntax seem overly > > clever. > > How do you feel about > > > f :: forall (a :: Type) -> a > > or > > > g :: (a :: Type) -> a > > Somehow, for me too, having the type of `a` listed makes it clearer. The > syntax for f echoes that in Coq, a long-standing dependently typed > language, but it uses , instead of ->. The type of `a` is optional. (An > implicit parameter is put in braces.) The syntax for g echoes that in Agda > and Idris; the type of `a` is not optional. Haskell cannot use the syntax > for `g`, because it looks like a kind annotation. > > In the end, I've never loved the forall ... -> syntax, but I've never seen > anything better. The suggestions you make are akin to those in > https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-727907040. > This alternative might work out, but I've never seen this approach taken in > another language, and it would be quite different from what we have today. > > > > If I had to explain `forall a -> a` to one of my > > Haskell-curious colleagues, I'd have to say "Oh that means you pass > > the name of a type to the function" -- something they'd have no chance > > of figuring out on their own! The 'forall' comes across as > > meaningless. (Case in point: I had no idea what the syntax meant when > > I saw it -- but I'm already invested enough to go digging.) > > I agree that the new syntax is not adequately self-describing. > > > > > I guess my question, then, is if there is some way to make this syntax > > more intuitive for users! > > I agree! But I somehow don't think separating out all the pieces will make > it easier, in the end. > > Richard > > > > > On Wed, Nov 18, 2020 at 10:10 PM Carter Schonwald > > wrote: > >> > >> I do think explaining it relative to the explicit vs implicit arg > syntax of agda function argument syntax. > >> > >> f: Forall a . B is used with f x. This relates to the new forall -> > syntax. > >> > >> g: forall {c}. D is used either as f or f {x}, aka implicit or forcing > it to be explicit. This maps to our usual Haskell forall with explicit {} > being the @ analogue > >> > >> On Wed, Nov 18, 2020 at 12:09 PM Iavor Diatchki < > iavor.diatchki at gmail.com> wrote: > >>> > >>> Semantically, `forall a -> a -> Int` is the same as `forall a. a -> > Int`. The two only differ in how you use them: > >>> * For the first one, you have to explicitly provide the type to use > for `a` at every call site, while > >>> * for the second one, you usually omit the type and let GHC infer it. > >>> > >>> So overall I think it's a pretty simple idea. For me it's hard to see > that from the text in #281, but I think a lot of the complexity there > >>> is about a fancy notation for explicitly providing the type at call > sites. > >>> > >>> -Iavor > >>> > >>> > >>> > >>> On Wed, Nov 18, 2020 at 9:51 AM Richard Eisenberg > wrote: > >>>> > >>>> Hi Bryan, > >>>> > >>>> First off, sorry if my first response was a bit snippy -- it wasn't > meant to be, and I appreciate the angle you're taking in your question. I > just didn't understand it! > >>>> > >>>> This second question is easier to answer. I say "forall a arrow a > arrow Int". > >>>> > >>>> But I still think there may be a deeper question here left > unanswered... > >>>> > >>>> Richard > >>>> > >>>> On Nov 18, 2020, at 6:11 AM, Bryan Richter wrote: > >>>> > >>>> Yeah, sorry, I think I'm in a little over my head here. :) But I > think I can ask a more answerable question now: how does one pronounce > "forall a -> a -> Int"? > >>>> > >>>> Den tis 17 nov. 2020 16:27Richard Eisenberg skrev: > >>>>> > >>>>> Hi Bryan, > >>>>> > >>>>> I don't think I understand what you're getting at here. The > difference between `forall b .` and `forall b ->` is only that the choice > of b must be made explicit. Importantly, a function of type e.g. `forall b > -> b -> b` can *not* pattern-match on the choice of type; it can bind a > variable that will be aliased to b, but it cannot pattern-match (say, > against Int). Given this, can you describe how `forall b ->` violates your > intuition for the keyword "forall"? > >>>>> > >>>>> Thanks! > >>>>> Richard > >>>>> > >>>>>> On Nov 17, 2020, at 1:47 AM, Bryan Richter wrote: > >>>>>> > >>>>>> Dear forall ghc-devs. ghc-devs, > >>>>>> > >>>>>> As I read through the "Visible 'forall' in types of terms" > >>>>>> proposal[1], I stumbled over something that isn't relevant to the > >>>>>> proposal itself, so I thought I would bring it here. > >>>>>> > >>>>>> Given > >>>>>> > >>>>>> f :: forall a. a -> a (1) > >>>>>> > >>>>>> I intuitively understand the 'forall' in (1) to represent the phrase > >>>>>> "for all". I would read (1) as "For all objects a in Hask, f is some > >>>>>> relation from a to a." > >>>>>> > >>>>>> After reading the proposal, I think my intuition may be wrong, > since I > >>>>>> discovered `forall a ->`. This means something similar to, but > >>>>>> practically different from, `forall a.`. Thus it seems like 'forall' > >>>>>> is now simply used as a sigil to represent "here is where some > special > >>>>>> parameter goes". It could as well be an emoji. > >>>>>> > >>>>>> What's more, the practical difference between the two forms is > *only* > >>>>>> distinguished by ` ->` versus `.`. That's putting quite a lot of > >>>>>> meaning into a rather small number of pixels, and further reduces > any > >>>>>> original connection to meaning that 'forall' might have had. > >>>>>> > >>>>>> I won't object to #281 based only on existing syntax, but I *do* > >>>>>> object to the existing syntax. :) Is this a hopeless situation, or > is > >>>>>> there any possibility of bringing back meaning to the syntax of > >>>>>> "dependent quantifiers"? > >>>>>> > >>>>>> -Bryan > >>>>>> > >>>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/281 > >>>>>> _______________________________________________ > >>>>>> 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 > >> > >> _______________________________________________ > >> 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 rae at richarde.dev Thu Dec 3 15:56:57 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 3 Dec 2020 15:56:57 +0000 Subject: Use of forall as a sigil In-Reply-To: References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> Message-ID: <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> > On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: > > Consider `forall a -> a -> a`. There's still an implicit universal quantification that is assumed, right? No, there isn't, and I think this is the central point of confusion. A function of type `forall a -> a -> a` does work for all types `a`. So I think the keyword is appropriate. The only difference is that we must state what `a` is explicitly. I thus respectfully disagree with > But somewhere, an author decided to reuse the same keyword to herald a type argument. It seems they stopped thinking about the meaning of the word itself, saw that it was syntactically in the right spot, and borrowed it to mean something else. Does this help clarify? And if it does, is there a place you can direct us to where the point could be made more clearly? I think you're far from the only one who has tripped here. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From b at chreekat.net Thu Dec 3 16:11:53 2020 From: b at chreekat.net (Bryan Richter) Date: Thu, 3 Dec 2020 18:11:53 +0200 Subject: Use of forall as a sigil In-Reply-To: <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> Message-ID: I must be confused, because it sounds like you are contradicting yourself. :) In one sentence you say that there is no assumed universal quantification going on, and in the next you say that the function does indeed work for all types. Isn't that the definition of universal quantification? (We're definitely getting somewhere interesting!) Den tors 3 dec. 2020 17:56Richard Eisenberg skrev: > > > On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: > > Consider `forall a -> a -> a`. There's still an implicit universal > quantification that is assumed, right? > > > No, there isn't, and I think this is the central point of confusion. A > function of type `forall a -> a -> a` does work for all types `a`. So I > think the keyword is appropriate. The only difference is that we must state > what `a` is explicitly. I thus respectfully disagree with > > But somewhere, an author decided to reuse the same keyword to herald a > type argument. It seems they stopped thinking about the meaning of the word > itself, saw that it was syntactically in the right spot, and borrowed it to > mean something else. > > > Does this help clarify? And if it does, is there a place you can direct us > to where the point could be made more clearly? I think you're far from the > only one who has tripped here. > > Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladislav at serokell.io Thu Dec 3 16:21:12 2020 From: vladislav at serokell.io (Vladislav Zavialov) Date: Thu, 3 Dec 2020 19:21:12 +0300 Subject: Use of forall as a sigil In-Reply-To: References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> Message-ID: There is no *implicit* universal quantification in that example, but there is an explicit quantifier. It is written as follows: forall a -> which is entirely analogous to: forall a. in all ways other than the additional requirement to instantiate the type vatiable visibly at use sites. - Vlad On Thu, Dec 3, 2020, 19:12 Bryan Richter wrote: > I must be confused, because it sounds like you are contradicting yourself. > :) In one sentence you say that there is no assumed universal > quantification going on, and in the next you say that the function does > indeed work for all types. Isn't that the definition of universal > quantification? > > (We're definitely getting somewhere interesting!) > > Den tors 3 dec. 2020 17:56Richard Eisenberg skrev: > >> >> >> On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: >> >> Consider `forall a -> a -> a`. There's still an implicit universal >> quantification that is assumed, right? >> >> >> No, there isn't, and I think this is the central point of confusion. A >> function of type `forall a -> a -> a` does work for all types `a`. So I >> think the keyword is appropriate. The only difference is that we must state >> what `a` is explicitly. I thus respectfully disagree with >> >> But somewhere, an author decided to reuse the same keyword to herald a >> type argument. It seems they stopped thinking about the meaning of the word >> itself, saw that it was syntactically in the right spot, and borrowed it to >> mean something else. >> >> >> Does this help clarify? And if it does, is there a place you can direct >> us to where the point could be made more clearly? I think you're far from >> the only one who has tripped here. >> >> Richard >> > _______________________________________________ > 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 rae at richarde.dev Thu Dec 3 16:24:58 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 3 Dec 2020 16:24:58 +0000 Subject: Use of forall as a sigil In-Reply-To: References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> Message-ID: <010f0176296bc984-dd903bab-37f2-4643-a150-c8074c2bf42e-000000@us-east-2.amazonses.com> > On Dec 3, 2020, at 11:11 AM, Bryan Richter wrote: > > I must be confused, because it sounds like you are contradicting yourself. :) In one sentence you say that there is no assumed universal quantification going on, and in the next you say that the function does indeed work for all types. Isn't that the definition of universal quantification? I agree with Vlad's comment here: There *is* universal quantification here, but there is not *implicit* universal quantification, as it's *explicit*. You've made the universal quantification with your `forall a ->`. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Thu Dec 3 16:39:06 2020 From: eric at seidel.io (Eric Seidel) Date: Thu, 03 Dec 2020 11:39:06 -0500 Subject: Use of forall as a sigil In-Reply-To: <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> Message-ID: <6ed95415-867a-4eae-9050-8b7b844e85cc@www.fastmail.com> I think the confusion for me is that I've trained myself to think of `forall` as explicitly introducing an implicit argument, and `->` as introducing an explicit argument. So the syntax `forall a ->` looks to me like a contradiction. On Thu, Dec 3, 2020, at 10:56, Richard Eisenberg wrote: > > > > On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: > > > > Consider `forall a -> a -> a`. There's still an implicit universal quantification that is assumed, right? > > No, there isn't, and I think this is the central point of confusion. A > function of type `forall a -> a -> a` does work for all types `a`. So I > think the keyword is appropriate. The only difference is that we must > state what `a` is explicitly. I thus respectfully disagree with > > > But somewhere, an author decided to reuse the same keyword to herald > a type argument. It seems they stopped thinking about the meaning of > the word itself, saw that it was syntactically in the right spot, and > borrowed it to mean something else. > Does this help clarify? And if it does, is there a place you can direct > us to where the point could be made more clearly? I think you're far > from the only one who has tripped here. > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > From sylvain at haskus.fr Thu Dec 3 17:31:57 2020 From: sylvain at haskus.fr (Sylvain Henry) Date: Thu, 3 Dec 2020 18:31:57 +0100 Subject: Use of forall as a sigil In-Reply-To: References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> Message-ID: I don't know if this has been discussed but couldn't we reuse the lambda abstraction syntax for this? That is instead of writing: forall a -> Write: \a -> Sylvain On 03/12/2020 17:21, Vladislav Zavialov wrote: > There is no *implicit* universal quantification in that example, but > there is an explicit quantifier. It is written as follows: > >   forall a -> > > which is entirely analogous to: > >   forall a. > > in all ways other than the additional requirement to instantiate the > type vatiable visibly at use sites. > > - Vlad > > > On Thu, Dec 3, 2020, 19:12 Bryan Richter > wrote: > > I must be confused, because it sounds like you are contradicting > yourself. :) In one sentence you say that there is no assumed > universal quantification going on, and in the next you say that > the function does indeed work for all types. Isn't that the > definition of universal quantification? > > (We're definitely getting somewhere interesting!) > > Den tors 3 dec. 2020 17:56Richard Eisenberg > skrev: > > > >> On Dec 3, 2020, at 10:23 AM, Bryan Richter > > wrote: >> >> Consider `forall a -> a -> a`. There's still an implicit >> universal quantification that is assumed, right? > > No, there isn't, and I think this is the central point of > confusion. A function of type `forall a -> a -> a` does work > for all types `a`. So I think the keyword is appropriate. The > only difference is that we must state what `a` is explicitly. > I thus respectfully disagree with > >> But somewhere, an author decided to reuse the same keyword to >> herald a type argument. It seems they stopped thinking about >> the meaning of the word itself, saw that it was syntactically >> in the right spot, and borrowed it to mean something else. > > Does this help clarify? And if it does, is there a place you > can direct us to where the point could be made more clearly? I > think you're far from the only one who has tripped here. > > Richard > > _______________________________________________ > 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 b at chreekat.net Thu Dec 3 19:24:27 2020 From: b at chreekat.net (Bryan Richter) Date: Thu, 3 Dec 2020 21:24:27 +0200 Subject: Use of forall as a sigil In-Reply-To: <6ed95415-867a-4eae-9050-8b7b844e85cc@www.fastmail.com> References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> <6ed95415-867a-4eae-9050-8b7b844e85cc@www.fastmail.com> Message-ID: Hm, yes, I might share Eric's intuition. I think I'm starting to get it, though. It originally sounded to me like "forall a ->" was being introduced as a new syntax for function arguments. In fact, it is a new syntax for quantification -- one that happens to borrow the syntax for function application. And well it might, because the sort of quantification it introduces is one that requires passing the name of a type to the function! Den tors 3 dec. 2020 18:39Eric Seidel skrev: > I think the confusion for me is that I've trained myself to think of > `forall` as explicitly introducing an implicit argument, and `->` > as introducing an explicit argument. So the syntax `forall a ->` > looks to me like a contradiction. > > On Thu, Dec 3, 2020, at 10:56, Richard Eisenberg wrote: > > > > > > > On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: > > > > > > Consider `forall a -> a -> a`. There's still an implicit universal > quantification that is assumed, right? > > > > No, there isn't, and I think this is the central point of confusion. A > > function of type `forall a -> a -> a` does work for all types `a`. So I > > think the keyword is appropriate. The only difference is that we must > > state what `a` is explicitly. I thus respectfully disagree > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krz.gogolewski at gmail.com Thu Dec 3 21:32:35 2020 From: krz.gogolewski at gmail.com (Krzysztof Gogolewski) Date: Thu, 3 Dec 2020 22:32:35 +0100 Subject: Use of forall as a sigil In-Reply-To: References: <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com> <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com> <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com> <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com> Message-ID: We should not reuse the lambda abstraction syntax for foralls. One is defining a function, and the other a function type. With Dependent Haskell, we could have: type T = forall a -> Maybe a type R = \a -> Maybe a Here, T has kind * and (\_ -> Nothing) is a value of type T, while R has kind * -> * and could be defined with 'type R a = Maybe a'. On Thu, Dec 3, 2020 at 6:32 PM Sylvain Henry wrote: > > I don't know if this has been discussed but couldn't we reuse the lambda abstraction syntax for this? > > That is instead of writing: forall a -> > Write: \a -> > > Sylvain > > > On 03/12/2020 17:21, Vladislav Zavialov wrote: > > There is no *implicit* universal quantification in that example, but there is an explicit quantifier. It is written as follows: > > forall a -> > > which is entirely analogous to: > > forall a. > > in all ways other than the additional requirement to instantiate the type vatiable visibly at use sites. > > - Vlad > > > On Thu, Dec 3, 2020, 19:12 Bryan Richter wrote: >> >> I must be confused, because it sounds like you are contradicting yourself. :) In one sentence you say that there is no assumed universal quantification going on, and in the next you say that the function does indeed work for all types. Isn't that the definition of universal quantification? >> >> (We're definitely getting somewhere interesting!) >> >> Den tors 3 dec. 2020 17:56Richard Eisenberg skrev: >>> >>> >>> >>> On Dec 3, 2020, at 10:23 AM, Bryan Richter wrote: >>> >>> Consider `forall a -> a -> a`. There's still an implicit universal quantification that is assumed, right? >>> >>> >>> No, there isn't, and I think this is the central point of confusion. A function of type `forall a -> a -> a` does work for all types `a`. So I think the keyword is appropriate. The only difference is that we must state what `a` is explicitly. I thus respectfully disagree with >>> >>> But somewhere, an author decided to reuse the same keyword to herald a type argument. It seems they stopped thinking about the meaning of the word itself, saw that it was syntactically in the right spot, and borrowed it to mean something else. >>> >>> >>> Does this help clarify? And if it does, is there a place you can direct us to where the point could be made more clearly? I think you're far from the only one who has tripped here. >>> >>> Richard >> >> _______________________________________________ >> 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 john.ericson at obsidian.systems Fri Dec 4 03:35:17 2020 From: john.ericson at obsidian.systems (John Ericson) Date: Thu, 3 Dec 2020 22:35:17 -0500 Subject: Using a development snapshot of happy In-Reply-To: <87o8nqfht7.fsf@smart-cactus.org> References: <87o8nqfht7.fsf@smart-cactus.org> Message-ID: <92a1a86e-d48b-359a-9310-38fcb78ceaeb@obsidian.systems> Seeing https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4560 stuck on needing a new version of Alex reminded me of this. Ben raises a good point on Happy bootstrapping from itself making this a pain, but I'd hope we could just get around this by vendoring the generated happy parser in the happy repo. In fact their two ways to do this: - as a permanent change, in which case we'd want to write a script to update the vendor instead of the custom sdist that is is the point of the Makefile. - in a separate "master-sdist" branch of generated sdists, which GHC would track with the submodule instead of master. While I'm rarely for vendoring generated code, breaking a bootstrap cycle is a pretty darn good reason. Also this is rather benign case of bootstrap artifact vendoring as:  - Generated happy code is a lot easier to understand than machine code at scale  - Ken Thompson attacks on the parser scare me less than elsewhere in the compiler Finally If all that is still too ugly, well, it would be nice to have a parser-combinator implementation of the same functionality that can double as a oracle for testing. Cheers, John On 8/4/20 1:21 PM, Ben Gamari wrote: > Vladislav Zavialov writes: > >> Hi ghc-devs, >> >> I’m working on the unification of parsers for terms and types, and one >> of the things I’d really like to make use of is a feature I >> implemented in ‘happy’ in October 2019 (9 months ago): >> >> https://github.com/simonmar/happy/pull/153 >> >> It’s been merged upstream, but there has been no release of ‘happy’, >> despite repeated requests: >> >> 1. I asked for a release in December: https://github.com/simonmar/happy/issues/164 >> 2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168 >> >> I see two solutions here: >> >> a) Find a co-maintainer for ‘happy’ who could make releases more >> frequently (I understand the current maintainers probably don’t have >> the time to do it). >> b) Use a development snapshot of ‘happy’ in GHC >> >> Maybe we need to do both, but one reason I’d like to see (b) in >> particular happen is that I can imagine introducing more features to >> ‘happy’ for use in GHC, and it’d be nice not to wait for a release >> every time. For instance, there are some changes I’d like to make to >> happy/alex in order to implement #17750 >> >> So here are two questions I have: >> >> 1. Are there any objections to this idea? > I'm not entirely keen on the idea: while the cost of the submodule > itself is pretty low (happy is a small package which takes little time > to build), I am skeptical of addressing social issues like happy's lack > of maintenance with technical solutions. Ultimately, shipping happy as a > submodule would merely kick the current problem down the road: > eventually (when we release GHC) we will need a happy release. Unless > the underlying maintainership problem is addressed we will end up right > back where we are today. > > Moreover, note that happy requires happy as a build dependency so we won't be > able to drop it as a build dependency of GHC even if we do include it as > a submodule. > > For this reason, I would weakly prefer that we first find a maintainer > and try to get a release out before jumping straight to adding happy as > a submodule. I will try to bring up the matter with Simon Marlow to see > if we can't find a solution here. > >> 2. If not, could someone more familiar with the build process guide >> me as to how this should be implemented? Do I add ‘happy’ as a >> submodule and change something in the ./configure script, or is >> there more to it? Do I need to modify make/hadrian, and if so, then >> how? >> > It will be a tad more involved than this. We will need to teach the > build systems to build Happy, use the configure executable, and update > the source distribution packaging rules to include the new submodule. > Moreover, happy (unfortunately) has a make-based build system which will > need to be used to generate its parser. > > Updating the build systems likely won't be difficult, but there isn't clear > documentation on what it will involve. This will really be a matter of > finding a similar existing case (e.g. genprimops, perhaps?), following > it as a model, and figuring out how to fill any gaps. > > Moreover, build system logic is inevitably a bug-nest; adding the same > logic twice greatly increases the chance that we will have (two sets of) > bugs that will only be caught post-release. For me, this underscores the > need to first try to make the existing decoupled situation work before > moving to a vendored solution. > > Cheers, > > - Ben > > _______________________________________________ > 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 vladislav at serokell.io Fri Dec 4 06:17:03 2020 From: vladislav at serokell.io (Vladislav Zavialov) Date: Fri, 4 Dec 2020 09:17:03 +0300 Subject: Using a development snapshot of happy In-Reply-To: <92a1a86e-d48b-359a-9310-38fcb78ceaeb@obsidian.systems> References: <87o8nqfht7.fsf@smart-cactus.org> <92a1a86e-d48b-359a-9310-38fcb78ceaeb@obsidian.systems> Message-ID: FWIW I have a parser-generator implementation here https://github.com/simonmar/happy/pull/170 On Fri, Dec 4, 2020, 06:35 John Ericson wrote: > Seeing https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4560 stuck on > needing a new version of Alex reminded me of this. > > Ben raises a good point on Happy bootstrapping from itself making this a > pain, but I'd hope we could just get around this by vendoring the generated > happy parser in the happy repo. In fact their two ways to do this: > > - as a permanent change, in which case we'd want to write a script to > update the vendor instead of the custom sdist that is is the point of the > Makefile. > > - in a separate "master-sdist" branch of generated sdists, which GHC would > track with the submodule instead of master. > > While I'm rarely for vendoring generated code, breaking a bootstrap cycle > is a pretty darn good reason. Also this is rather benign case of bootstrap > artifact vendoring as: > > - Generated happy code is a lot easier to understand than machine code at > scale > > - Ken Thompson attacks on the parser scare me less than elsewhere in the > compiler > > Finally If all that is still too ugly, well, it would be nice to have a > parser-combinator implementation of the same functionality that can double > as a oracle for testing. > > Cheers, > > John > On 8/4/20 1:21 PM, Ben Gamari wrote: > > Vladislav Zavialov writes: > > > Hi ghc-devs, > > I’m working on the unification of parsers for terms and types, and one > of the things I’d really like to make use of is a feature I > implemented in ‘happy’ in October 2019 (9 months ago): > > https://github.com/simonmar/happy/pull/153 > > It’s been merged upstream, but there has been no release of ‘happy’, > despite repeated requests: > > 1. I asked for a release in December: https://github.com/simonmar/happy/issues/164 > 2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168 > > I see two solutions here: > > a) Find a co-maintainer for ‘happy’ who could make releases more > frequently (I understand the current maintainers probably don’t have > the time to do it). > b) Use a development snapshot of ‘happy’ in GHC > > Maybe we need to do both, but one reason I’d like to see (b) in > particular happen is that I can imagine introducing more features to > ‘happy’ for use in GHC, and it’d be nice not to wait for a release > every time. For instance, there are some changes I’d like to make to > happy/alex in order to implement #17750 > > So here are two questions I have: > > 1. Are there any objections to this idea? > > > I'm not entirely keen on the idea: while the cost of the submodule > itself is pretty low (happy is a small package which takes little time > to build), I am skeptical of addressing social issues like happy's lack > of maintenance with technical solutions. Ultimately, shipping happy as a > submodule would merely kick the current problem down the road: > eventually (when we release GHC) we will need a happy release. Unless > the underlying maintainership problem is addressed we will end up right > back where we are today. > > Moreover, note that happy requires happy as a build dependency so we won't be > able to drop it as a build dependency of GHC even if we do include it as > a submodule. > > For this reason, I would weakly prefer that we first find a maintainer > and try to get a release out before jumping straight to adding happy as > a submodule. I will try to bring up the matter with Simon Marlow to see > if we can't find a solution here. > > > 2. If not, could someone more familiar with the build process guide > me as to how this should be implemented? Do I add ‘happy’ as a > submodule and change something in the ./configure script, or is > there more to it? Do I need to modify make/hadrian, and if so, then > how? > > > It will be a tad more involved than this. We will need to teach the > build systems to build Happy, use the configure executable, and update > the source distribution packaging rules to include the new submodule. > Moreover, happy (unfortunately) has a make-based build system which will > need to be used to generate its parser. > > Updating the build systems likely won't be difficult, but there isn't clear > documentation on what it will involve. This will really be a matter of > finding a similar existing case (e.g. genprimops, perhaps?), following > it as a model, and figuring out how to fill any gaps. > > Moreover, build system logic is inevitably a bug-nest; adding the same > logic twice greatly increases the chance that we will have (two sets of) > bugs that will only be caught post-release. For me, this underscores the > need to first try to make the existing decoupled situation work before > moving to a vendored solution. > > Cheers, > > - Ben > > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Fri Dec 4 12:00:49 2020 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 4 Dec 2020 14:00:49 +0200 Subject: Using a development snapshot of happy In-Reply-To: References: Message-ID: Would you be happy to be a maintainer of happy? Sorry, couldn't resist, but I ask seriously. - Oleg On 2.8.2020 10.43, Vladislav Zavialov wrote: > Hi ghc-devs, > > I’m working on the unification of parsers for terms and types, and one of the things I’d really like to make use of is a feature I implemented in ‘happy’ in October 2019 (9 months ago): > > https://github.com/simonmar/happy/pull/153 > > It’s been merged upstream, but there has been no release of ‘happy’, despite repeated requests: > > 1. I asked for a release in December: https://github.com/simonmar/happy/issues/164 > 2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168 > > I see two solutions here: > > a) Find a co-maintainer for ‘happy’ who could make releases more frequently (I understand the current maintainers probably don’t have the time to do it). > b) Use a development snapshot of ‘happy’ in GHC > > Maybe we need to do both, but one reason I’d like to see (b) in particular happen is that I can imagine introducing more features to ‘happy’ for use in GHC, and it’d be nice not to wait for a release every time. For instance, there are some changes I’d like to make to happy/alex in order to implement #17750 > > So here are two questions I have: > > 1. Are there any objections to this idea? > 2. If not, could someone more familiar with the build process guide me as to how this should be implemented? Do I add ‘happy’ as a submodule and change something in the ./configure script, or is there more to it? Do I need to modify make/hadrian, and if so, then how? > > Thanks, > - Vlad > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From john.ericson at obsidian.systems Fri Dec 4 20:37:34 2020 From: john.ericson at obsidian.systems (John Ericson) Date: Fri, 4 Dec 2020 15:37:34 -0500 Subject: Using a development snapshot of happy In-Reply-To: References: Message-ID: I'll take the bait :) and offer co-maintain both Happy and Alex, on the condition that we agree to make them submodules in GHC. John On 12/4/20 7:00 AM, Oleg Grenrus wrote: > Would you be happy to be a maintainer of happy? > > Sorry, couldn't resist, but I ask seriously. > > - Oleg > > On 2.8.2020 10.43, Vladislav Zavialov wrote: >> Hi ghc-devs, >> >> I’m working on the unification of parsers for terms and types, and one of the things I’d really like to make use of is a feature I implemented in ‘happy’ in October 2019 (9 months ago): >> >> https://github.com/simonmar/happy/pull/153 >> >> It’s been merged upstream, but there has been no release of ‘happy’, despite repeated requests: >> >> 1. I asked for a release in December: https://github.com/simonmar/happy/issues/164 >> 2. Ben asked for a release a month ago: https://github.com/simonmar/happy/issues/168 >> >> I see two solutions here: >> >> a) Find a co-maintainer for ‘happy’ who could make releases more frequently (I understand the current maintainers probably don’t have the time to do it). >> b) Use a development snapshot of ‘happy’ in GHC >> >> Maybe we need to do both, but one reason I’d like to see (b) in particular happen is that I can imagine introducing more features to ‘happy’ for use in GHC, and it’d be nice not to wait for a release every time. For instance, there are some changes I’d like to make to happy/alex in order to implement #17750 >> >> So here are two questions I have: >> >> 1. Are there any objections to this idea? >> 2. If not, could someone more familiar with the build process guide me as to how this should be implemented? Do I add ‘happy’ as a submodule and change something in the ./configure script, or is there more to it? Do I need to modify make/hadrian, and if so, then how? >> >> Thanks, >> - Vlad >> _______________________________________________ >> 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 juhpetersen at gmail.com Mon Dec 7 04:37:43 2020 From: juhpetersen at gmail.com (Jens Petersen) Date: Mon, 7 Dec 2020 12:37:43 +0800 Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released In-Reply-To: <873631g1e2.fsf@smart-cactus.org> References: <873631g1e2.fsf@smart-cactus.org> Message-ID: Very late followup, but I just wanted to share that Fedora users can install this now (stable since last week) with: sudo dnf module install ghc:9.0/default Thanks, Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Dec 8 03:50:30 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 8 Dec 2020 03:50:30 +0000 Subject: Help lead Haskell: Executive Director sought for Haskell Foundation Message-ID: <010f01764078da35-f8ff6647-14b8-4af0-b45a-18a342697dd7-000000@us-east-2.amazonses.com> Posting on behalf of the Haskell Foundation Working Group. Please forward widely! -------- The Haskell Foundation is seeking an Executive Director. Please find the job description here: https://haskell.foundation/ ed-job-description The Haskell Foundation (HF) is an independent, non-profit organization dedicated to driving Haskell adoption and open-source development. HF seeks a full-time Executive Director (ED) to lead and develop the organization going forward. The ED is responsible for furthering the HF’s mission and vision, ensuring that resources are in place to accomplish its goals. The HF is supported by an active group of volunteers, and the ED will be a key focal point for that community, in addition to hiring support staff. This is a salaried position. Salary will be commensurate with the experience, qualities, and location of the individual, and will also reflect the Foundation’s status as a non-profit organisation funded by donations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Dec 9 20:24:28 2020 From: ben at well-typed.com (Ben Gamari) Date: Wed, 09 Dec 2020 15:24:28 -0500 Subject: [ANNOUNCEMENT] Change in MR landing procedure Message-ID: <87zh2menie.fsf@smart-cactus.org> tl;dr. On Thursday 10 Dec, Marge-bot will be relocated to a retirement facility. Her duties will henceforth be carried out by GitLab's Merge Train functionality. Hi all, When GHC moved to GitLab two years ago the platform lacked a critical feature: the ability to manage a queue of merge requests slated to be merged. For the past two years we have been using @marge-bot for this functionality. While Marge has served us well, she also introduces her fair share of failure modes. In the meantime GitLab has grown proper support for our use-case in the form of the "merge train" mechanism [1]. In light of Marge's growing intransigence [2], I will grant her a well-earned retirement and begin using merge trains for merging MRs starting on Thursday. As a result, the workflow for adding a merge request to the merge queue will become a bit more straightforward: Instead of setting the MR's "assignee" to @marge-bot rather push the blue "Start/add to merge train" button. This adds the merge request to the merge queue. This is documented in the Wiki [3]. Apart from freeing us from the need to maintain Marge, this change also enables us to use GitLab's branch-squashing functionality, which Marge did not support. Do let me know if you have any questions or concerns. So long, Marge, and thanks for all of the commits. Cheers, - Ben [1] https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ [2] https://gitlab.haskell.org/ghc/ghc/-/issues/19034 [3] https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Thu Dec 10 06:10:37 2020 From: ben at well-typed.com (Ben Gamari) Date: Thu, 10 Dec 2020 01:10:37 -0500 Subject: [ANNOUNCEMENT] Change in MR landing procedure In-Reply-To: <87zh2menie.fsf@smart-cactus.org> References: <87zh2menie.fsf@smart-cactus.org> Message-ID: <87wnxqdwdi.fsf@smart-cactus.org> Ben Gamari writes: > tl;dr. On Thursday 10 Dec, Marge-bot will be relocated to a retirement > facility. Her duties will henceforth be carried out by GitLab's > Merge Train functionality. > > > Hi all, > > When GHC moved to GitLab two years ago the platform lacked a critical > feature: the ability to manage a queue of merge requests slated to be > merged. For the past two years we have been using @marge-bot for this > functionality. While Marge has served us well, she also introduces her > fair share of failure modes. > > In the meantime GitLab has grown proper support for our use-case in the > form of the "merge train" mechanism [1]. In light of Marge's growing > intransigence [2], I will grant her a well-earned retirement and begin > using merge trains for merging MRs starting on Thursday. > Unfortunately, on further testing I found a few additional features missing from GitLab's merge train implementation that precludes our use of it currently. It's possible that this will be fix in the near future but until then it looks like we will need to stick with Marge. I have opened #19046 to track the migration. Anyways, please continue to assign mergeable MR's to @marge-bot until further notice. I'll roll back the Wiki changes tomorrow. Apologies for the confusion! 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 chessai1996 at gmail.com Thu Dec 10 06:12:12 2020 From: chessai1996 at gmail.com (chessai) Date: Thu, 10 Dec 2020 00:12:12 -0600 Subject: [ANNOUNCEMENT] Change in MR landing procedure In-Reply-To: <87wnxqdwdi.fsf@smart-cactus.org> References: <87zh2menie.fsf@smart-cactus.org> <87wnxqdwdi.fsf@smart-cactus.org> Message-ID: No problem, thanks for the update Ben! Something to look forward to On Thu, Dec 10, 2020, 00:11 Ben Gamari wrote: > Ben Gamari writes: > > > tl;dr. On Thursday 10 Dec, Marge-bot will be relocated to a retirement > > facility. Her duties will henceforth be carried out by GitLab's > > Merge Train functionality. > > > > > > Hi all, > > > > When GHC moved to GitLab two years ago the platform lacked a critical > > feature: the ability to manage a queue of merge requests slated to be > > merged. For the past two years we have been using @marge-bot for this > > functionality. While Marge has served us well, she also introduces her > > fair share of failure modes. > > > > In the meantime GitLab has grown proper support for our use-case in the > > form of the "merge train" mechanism [1]. In light of Marge's growing > > intransigence [2], I will grant her a well-earned retirement and begin > > using merge trains for merging MRs starting on Thursday. > > > Unfortunately, on further testing I found a few additional features > missing from GitLab's merge train implementation that precludes our use > of it currently. It's possible that this will be fix in the near future > but until then it looks like we will need to stick with Marge. I have > opened #19046 to track the migration. > > Anyways, please continue to assign mergeable MR's to @marge-bot until > further notice. I'll roll back the Wiki changes tomorrow. > > Apologies for the confusion! > > Cheers, > > - Ben > _______________________________________________ > 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 lexi.lambda at gmail.com Tue Dec 15 05:51:33 2020 From: lexi.lambda at gmail.com (Alexis King) Date: Mon, 14 Dec 2020 23:51:33 -0600 Subject: Nested constructed product results? Message-ID: <7425B443-C462-4347-90D9-3B7637D55216@gmail.com> Hi all, I spent some time today looking into the performance of a program involving a parser type that looks something like this: data AnnotatedParser a = AnnotatedParser { annotation :: Annotation , parser :: String -> (Maybe a, String) } The `Annotation` records metadata about the structure of an `AnnotatedParser` that can be accessed statically (that is, without having to run the parser on some input). `AnnotatedParser`s are built from various primitive constructors and composed using various combinators. These combinators end up looking something like this: (<+>) :: AnnotatedParser a -> AnnotatedParser b -> AnnotatedParser (a, b) AnnotatedParser ann1 f <+> AnnotatedParser ann2 g = AnnotatedParser { annotation = Seq ann1 ann2 , parser = \s1 -> let !(a, s2) = f s1 !(b, s3) = g s2 in ((,) <$> a <*> b, s3) } Use of these combinators leads to the construction and subsequent case analysis of numerous `AnnotatedParser` closures. Happily, constructed product result[1] analysis kicks in and rewrites such combinators to cut down on the needless boxing, leading to worker/wrapper splits like this: $w<+> :: Annotation -> (String -> (Maybe a, String)) -> Annotation -> (String -> (Maybe b, String)) -> (# Annotation, String -> (Maybe (a, b), String) #) $w<+> ann1 f ann2 g = (# Seq ann1 ann2 , \s1 -> let !(a, s2) = f s1 !(b, s3) = g s2 in ((,) <$> a <*> b, s3) #) <+> :: AnnotatedParser a -> AnnotatedParser b -> AnnotatedParser (a, b) <+> (AnnotatedParser ann1 f) (AnnotatedParser ann2 g) = case $w<+> ann1 f ann2 g of (# a, b #) -> AnnotatedParser a b {-# INLINE <+> #-} This is great, and it cuts down on allocation significantly, but there is still something unsatisfying about it: the `parser` function inside the record is not affected by CPR! This is a shame, because essentially all use sites immediately deconstruct the pair, making it a prime candidate for unboxing. Ideally, we’d like to get this, instead: $w<+> :: Annotation -> (String -> (Maybe a, String)) -> Annotation -> (String -> (Maybe b, String)) -> (# Annotation, String -> (# Maybe (a, b), String #) #) $w<+> ann1 f ann2 g = (# Seq ann1 ann2 , \s1 -> let !(a, s2) = f s1 !(b, s3) = g s2 in (# (,) <$> a <*> b, s3 #) #) In practice, little combinators like `$w<+>` are marked INLINE, so `f` and `g` are usually known rather than unknown calls. This nested CPR transformation would allow the tuple construction to fuse with the tuple deconstruction, eliminating quite a lot of unnecessary boxing/unboxing. Unfortunately, it seems as though GHC’s implementation of CPR is entirely first-order: although function arguments are given rich demand signatures, results are only described one level deep. But as the above example hopefully illustrates, that’s leaving significant optimization opportunities on the table! Hence, my questions: 1. Has this notion of “nested CPR” been explored at all before? 2. Does such an extension to CPR sound worth its weight? I peeked a little at GHC.Types.Cpr and GHC.Core.Opt.CprAnal, and it seems quite manageable to me, but I haven’t actually looked into an implementation attempt just yet. I’m mostly interested in whether others have thought about something like this and/or run into similar issues in the past, or if this is really an unusual construction. Thanks, Alexis [1]: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/cpr.pdf From sgraf1337 at gmail.com Tue Dec 15 08:20:11 2020 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 15 Dec 2020 09:20:11 +0100 Subject: Nested constructed product results? In-Reply-To: <7425B443-C462-4347-90D9-3B7637D55216@gmail.com> References: <7425B443-C462-4347-90D9-3B7637D55216@gmail.com> Message-ID: Hi Alexis, that's a very interesting example you have there! So far, what we referred to as Nested CPR concerned unboxing for returned nested *records*, e.g., the `annotation` field in your example. That's what I try to exploit in !1866 , which after a rebase that I'll hopefully be doing this week, some more sleuthing and then documenting what I did will finally make it into master. CPR'ing the Lambda, i.e., what is returned for `parser`, on the other hand, is a surprising new opportunity for what Nested CPR could do beyond unboxing records! And it's pretty simple, too: Because it's a function, we don't care about subtleties such as whether all callers actually evaluate the pair that deep (actually, that's wrong, as I realise below). I think it's entirely within the reach of !1866 today. So we could transform (provided that `(,) <$> a <*> b` inlines `<$>` and `<*>` and then will actually have the CPR property) AnnotatedParser ann1 f <+> AnnotatedParser ann2 g = AnnotatedParser { annotation = Seq ann1 ann2 , parser = \s1 -> let !(a, s2) = f s1 !(b, s3) = g s2 in ((,) <$> a <*> b, s3) } to $w<+> :: Annotation -> (String -> (Maybe a, String)) -> Annotation -> (String -> (Maybe b, String)) -> (# Annotation, String -> (# Maybe (a, b), String #) #) $w<+> ann1 f ann2 g = (# Seq ann1 ann2 , \s1 -> case (\s1 -> let !(a, s2) = f s1 !(b, s3) = g s2 in ((,) <$> a <*> b) s1 of (p, q) -> (#p, q#), s3) #) <+> :: AnnotatedParser a -> AnnotatedParser b -> AnnotatedParser (a, b) <+> (AnnotatedParser ann1 f) (AnnotatedParser ann2 g) = case $w<+> ann1 f ann2 g of (# a, b #) -> AnnotatedParser (\s1 -> case a s1 of (# p, q#) -> (p, q)) b {-# INLINE <+> #-} Actually writing out the transformation tells me that this isn't always a win: We now have to allocate a lambda in the wrapper. That is only a win if that lambda cancels away at call sites! So we have to make sure that all call sites of the wrapper actually call the `parser`, so that the lambda simplifies away. If it doesn't, we have a situation akin to reboxing. So I was wrong above when I said "we don't care about subtleties such as whether all callers actually evaluate the pair that deep": We very much need to know whether all call sites call the lambda. Luckily, I implemented just that for exploitation by Nested CPR! That's the reason why I need to rebase !1866 now. I'll ḱeep you posted. --- You might wonder why CPR today doesn't care for lambdas. Well, they only make sense in nested scenarios (otherwise the function wasn't eta-expanded that far, for good reasons) and CPR currently doesn't bother unboxing records nestedly, which is what #18174 discusses and what !1866 tries to fix. Cheers, Sebastian Am Di., 15. Dez. 2020 um 06:52 Uhr schrieb Alexis King < lexi.lambda at gmail.com>: > Hi all, > > I spent some time today looking into the performance of a program > involving a parser type that looks something like this: > > data AnnotatedParser a = AnnotatedParser > { annotation :: Annotation > , parser :: String -> (Maybe a, String) > } > > The `Annotation` records metadata about the structure of an > `AnnotatedParser` that can be accessed statically (that is, without > having to run the parser on some input). `AnnotatedParser`s are built > from various primitive constructors and composed using various > combinators. These combinators end up looking something like this: > > (<+>) :: AnnotatedParser a -> AnnotatedParser b -> AnnotatedParser (a, > b) > AnnotatedParser ann1 f <+> AnnotatedParser ann2 g = AnnotatedParser > { annotation = Seq ann1 ann2 > , parser = \s1 -> > let !(a, s2) = f s1 > !(b, s3) = g s2 > in ((,) <$> a <*> b, s3) > } > > Use of these combinators leads to the construction and subsequent case > analysis of numerous `AnnotatedParser` closures. Happily, constructed > product result[1] analysis kicks in and rewrites such combinators to cut > down on the needless boxing, leading to worker/wrapper splits like this: > > $w<+> :: Annotation > -> (String -> (Maybe a, String)) > -> Annotation > -> (String -> (Maybe b, String)) > -> (# Annotation, String -> (Maybe (a, b), String) #) > $w<+> ann1 f ann2 g = > (# Seq ann1 ann2 > , \s1 -> let !(a, s2) = f s1 > !(b, s3) = g s2 > in ((,) <$> a <*> b, s3) #) > > <+> :: AnnotatedParser a -> AnnotatedParser b -> AnnotatedParser (a, b) > <+> (AnnotatedParser ann1 f) (AnnotatedParser ann2 g) = > case $w<+> ann1 f ann2 g of > (# a, b #) -> AnnotatedParser a b > {-# INLINE <+> #-} > > This is great, and it cuts down on allocation significantly, but there > is still something unsatisfying about it: the `parser` function inside > the record is not affected by CPR! This is a shame, because > essentially all use sites immediately deconstruct the pair, making it > a prime candidate for unboxing. Ideally, we’d like to get this, instead: > > $w<+> :: Annotation > -> (String -> (Maybe a, String)) > -> Annotation > -> (String -> (Maybe b, String)) > -> (# Annotation, String -> (# Maybe (a, b), String #) #) > $w<+> ann1 f ann2 g = > (# Seq ann1 ann2 > , \s1 -> let !(a, s2) = f s1 > !(b, s3) = g s2 > in (# (,) <$> a <*> b, s3 #) #) > > In practice, little combinators like `$w<+>` are marked INLINE, so `f` > and `g` are usually known rather than unknown calls. This nested CPR > transformation would allow the tuple construction to fuse with the > tuple deconstruction, eliminating quite a lot of unnecessary > boxing/unboxing. > > Unfortunately, it seems as though GHC’s implementation of CPR is > entirely first-order: although function arguments are given rich > demand signatures, results are only described one level deep. But as > the above example hopefully illustrates, that’s leaving significant > optimization opportunities on the table! Hence, my questions: > > 1. Has this notion of “nested CPR” been explored at all before? > 2. Does such an extension to CPR sound worth its weight? > > I peeked a little at GHC.Types.Cpr and GHC.Core.Opt.CprAnal, and it > seems quite manageable to me, but I haven’t actually looked into an > implementation attempt just yet. I’m mostly interested in whether > others have thought about something like this and/or run into similar > issues in the past, or if this is really an unusual construction. > > Thanks, > Alexis > > [1]: > https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/cpr.pdf > > _______________________________________________ > 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 ben at well-typed.com Wed Dec 16 00:03:57 2020 From: ben at well-typed.com (Ben Gamari) Date: Tue, 15 Dec 2020 19:03:57 -0500 Subject: Status and GHC's treatment of Haddock Message-ID: <875z52hb11.fsf@smart-cactus.org> Hi all, Sadly `master` has been broken for much of the day. The causal-chain is roughly the following: 1. Last week a haddock merge-request was prematurely merged by a haddock developer, despite not being compilable, to the `ghc-head` branch. 2. marge-bot failed during a merge on Sunday 3. On Monday I finished merging the half-merged batch manually, not aware of the inconsistent submodule state. However, while doing so some unintended changes crept in, relying on an unmerged haddock commit. 4. in an attempt to fix the inconsistent submodule state another developer merged the unmerged commit 5. I notice the unintentional commits on `master` and start to back them out 6. I note that even after backing out the unintentional commits the tree *still* doesn't build due to haddock 7. I perform a fair amount of head-scratching trying to figure out what is going on; eventually I find the non-building commit. 8. I eventually sort out what needs to be backed-out and in what order I take a few lessons from this: * manual merges, no matter how "straightforward", are always a vector for mistakes. I should have triple-checked my work before pushing manually pushing the half-merged branch. * haddock submodule changes going in prematurely come with a very high cost, especially if they don't build. It turns out I had run into the non-compilable haddock commit a few times last week but had chalked it up to in-flight changes. On the whole, I am really starting to wonder whether we can't improve our model for dealing with haddock; it is currently quite easy for haddock and GHC to enter an inconsistent state. Moreover, the fact that `haddock`'s `ghc-head` branch runs ahead of `master` means that we won't realize the problem until it's too late. One small improvement would be to move Haddock to GitLab. This would at least ensure that there is a clear connection between haddock MRs and their corresponding GHC changes. I have suggested this to Alex. Beyond this, it would be great if someone could step up to finish the hi-haddock change [1]. I suspect this refactoring has the potential to greatly improve this situation: the interface file AST tends to be more stable that the Core AST and has significantly less surface area. After this is in place Haddock could then use either its own AST or a frozen HsSyn AST from GHC (faciliated by TTG) internally, greatly reducing the coupling between Haddock and GHC. Any takers? 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 ben at well-typed.com Sun Dec 20 00:21:42 2020 From: ben at well-typed.com (Ben Gamari) Date: Sat, 19 Dec 2020 19:21:42 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.10.3 released Message-ID: <87wnxdfht8.fsf@smart-cactus.org> Hello all, The GHC team is happy to announce the release of GHC 8.10.3. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/8.10.3/ GHC 8.10.3 fixes a number of issues in present in GHC 8.10.2 including: * Numerous stability improves on Windows * More robust support for architectures with weak memory ordering guarantees (e.g. modern ARM hardware). * GHC can now split dynamic objects to accomodate macOS' RPATH size limitation when building large projects (#14444) * Several correctness bugs in the new low-latency garbage collector * Many, many other bug-fixes Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running `xattr -cr .` on the unpacked tree before running `make install`. This situation will hopefully be improved for GHC 9.0.1 with the resolution of #17418 [1]. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/17418 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From shayne.fletcher.50 at gmail.com Sun Dec 20 14:29:22 2020 From: shayne.fletcher.50 at gmail.com (Shayne Fletcher) Date: Sun, 20 Dec 2020 09:29:22 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.10.3 released In-Reply-To: <87wnxdfht8.fsf@smart-cactus.org> References: <87wnxdfht8.fsf@smart-cactus.org> Message-ID: On Sat, Dec 19, 2020 at 7:23 PM Ben Gamari wrote: > Hello all, > > The GHC team is happy to announce the release of GHC 8.10.3. Source > and binary distributions are available at the usual place: > > https://downloads.haskell.org/ghc/8.10.3/ Thanks! There doesn't seem to be a ghc-8.10.3-release tag in the git at gitlab.haskell.org:ghc/ghc.git repository. Shouldn't there be? -- Shayne Fletcher -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Dec 20 17:27:07 2020 From: ben at well-typed.com (Ben Gamari) Date: Sun, 20 Dec 2020 12:27:07 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.10.3 released In-Reply-To: References: <87wnxdfht8.fsf@smart-cactus.org> Message-ID: <87tusgfkwr.fsf@smart-cactus.org> Shayne Fletcher writes: > On Sat, Dec 19, 2020 at 7:23 PM Ben Gamari wrote: > >> Hello all, >> >> The GHC team is happy to announce the release of GHC 8.10.3. Source >> and binary distributions are available at the usual place: >> >> https://downloads.haskell.org/ghc/8.10.3/ > > > Thanks! > > There doesn't seem to be a ghc-8.10.3-release tag in > the git at gitlab.haskell.org:ghc/ghc.git repository. Shouldn't there be? > Indeed. Fixed! 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 lonetiger at gmail.com Sun Dec 20 22:30:07 2020 From: lonetiger at gmail.com (Phyx) Date: Sun, 20 Dec 2020 22:30:07 +0000 Subject: [ANNOUNCE] Glasgow Haskell Compiler 8.10.3 released In-Reply-To: <87wnxdfht8.fsf@smart-cactus.org> References: <87wnxdfht8.fsf@smart-cactus.org> Message-ID: Hi Ben, The package ghc-8.10.3-x86_64-unknown-mingw32-integer-simple.tar.xz reports Tamar at PowPow /t/ghc> ./ghc-8.10.3/bin/ghc.exe -v Glasgow Haskell Compiler, Version 8.10.3, stage 2 booted by GHC version 8.8.3 ... wired-in package integer-wired-in mapped to integer-gmp-1.0.3.0 ... Tamar at PowPow /t/ghc> ./ghc-8.10.3/bin/ghc-pkg list | grep integer integer-gmp-1.0.3.0 Is this package correct? The naming seems different from the one in the 9.0.1-alpha as well (that one had an explicit -integer-simple in the folder name when uncompressed) Thanks, Tamar On Sun, Dec 20, 2020 at 12:23 AM Ben Gamari wrote: > Hello all, > > The GHC team is happy to announce the release of GHC 8.10.3. Source > and binary distributions are available at the usual place: > > https://downloads.haskell.org/ghc/8.10.3/ > > GHC 8.10.3 fixes a number of issues in present in GHC 8.10.2 including: > > * Numerous stability improves on Windows > > * More robust support for architectures with weak memory ordering > guarantees (e.g. modern ARM hardware). > > * GHC can now split dynamic objects to accomodate macOS' RPATH size > limitation when building large projects (#14444) > > * Several correctness bugs in the new low-latency garbage collector > > * Many, many other bug-fixes > > Note that at the moment we still require that macOS Catalina users > exempt the binary distribution from the notarization requirement by > running `xattr -cr .` on the unpacked tree before running `make install`. > This situation will hopefully be improved for GHC 9.0.1 with the > resolution of #17418 [1]. > > Cheers, > > - Ben > > [1] https://gitlab.haskell.org/ghc/ghc/issues/17418 > _______________________________________________ > 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 ezyang at mit.edu Mon Dec 21 23:26:51 2020 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 21 Dec 2020 18:26:51 -0500 Subject: Fat interface files? In-Reply-To: <87eelsq3vb.fsf@smart-cactus.org> References: <87eelsq3vb.fsf@smart-cactus.org> Message-ID: <1608593101-sup-4821@naginata> Hi Ben, sorry about the late response. It looks like you've found https://gitlab.haskell.org/ghc/ghc/-/issues/10871 which I think pretty comprehensively discusses the issue as it is. Given the elapsed time it would probably make sense to reimplement from scratch; I don't recall this being too difficult to do. HAs anything else come up in the meantime? Edward Excerpts from Ben Gamari's message of 2020-10-20 12:06:03 -0400: > Hi Edward, > > While chatting with the ghc-ide folks recently I realized that it would > be useful to be able to preserve Core such that compilation can be > restarted (e.g. to be pushed down the bytecode pipeline to evaluate TH > splices). > > As I recall this is precisely what you implemented in your "fat > interface file" work. Do you recall what the state of this work was? Do > you have a branch with last-known-good work? Do you recall any tricky > questions that remained outstanding? > > Cheers, > > - Ben From nmichael at gmail.com Wed Dec 23 18:37:48 2020 From: nmichael at gmail.com (Neophytos Michael) Date: Wed, 23 Dec 2020 20:37:48 +0200 Subject: Troubles when building ghc Message-ID: I am having some trouble building ghc on ubuntu. I have ghc 8.8.4 installed on the machine. I pulled from the main repository and followed the instructions here: https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian Building with: ./hadrian/build -j it builds for a long time until it finally fails with the message below. I would appreciate some advice on how to fix this. Thank you, Neo =========================== Exit code: 1 Stderr and Stdout: _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3495:3: error: Variable not in scope: int16ToInt# :: Int# -> Int# | 3495 | int16ToInt# | ^^^^^^^^^^^ _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3520:3: error: Variable not in scope: int32ToInt# :: Int# -> Int# | 3520 | int32ToInt# | ^^^^^^^^^^^ =========================== On that line (in Lexer.hs) we see: #if __GLASGOW_HASKELL__ >= 901 int16ToInt# #endif (indexInt16OffAddr# arr off) #endif so we are in the "then" clause and somehow "int16ToInt#" is nowhere to be found. -- Neo -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Dec 23 19:10:18 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 23 Dec 2020 19:10:18 +0000 Subject: Troubles when building ghc In-Reply-To: References: Message-ID: <010f0176910255e9-55f9ed8c-5772-440c-a813-20c1940e72d8-000000@us-east-2.amazonses.com> Without having particular knowledge about this specific error: try upgrading `alex`, the tool that GHC uses to produce its lexer. It's possible a newer version of that tool will fix this problem. Richard > On Dec 23, 2020, at 1:37 PM, Neophytos Michael wrote: > > I am having some trouble building ghc on ubuntu. I have ghc 8.8.4 installed on the machine. I pulled from the main repository and followed the instructions here: https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian > > Building with: > ./hadrian/build -j > > it builds for a long time until it finally fails with the message below. I would appreciate some advice on how to fix this. > > Thank you, > Neo > > =========================== > Exit code: 1 > Stderr and Stdout: > _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3495:3: error: > Variable not in scope: int16ToInt# :: Int# -> Int# > | > 3495 | int16ToInt# > | ^^^^^^^^^^^ > > _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3520:3: error: > Variable not in scope: int32ToInt# :: Int# -> Int# > | > 3520 | int32ToInt# > | ^^^^^^^^^^^ > =========================== > On that line (in Lexer.hs) we see: > > #if __GLASGOW_HASKELL__ >= 901 > int16ToInt# > #endif > (indexInt16OffAddr# arr off) > #endif > > so we are in the "then" clause and somehow "int16ToInt#" is nowhere to be found. > > -- > Neo > > _______________________________________________ > 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 john.ericson at obsidian.systems Wed Dec 23 19:12:20 2020 From: john.ericson at obsidian.systems (John Ericson) Date: Wed, 23 Dec 2020 14:12:20 -0500 Subject: Troubles when building ghc In-Reply-To: <010f0176910255e9-55f9ed8c-5772-440c-a813-20c1940e72d8-000000@us-east-2.amazonses.com> References: <010f0176910255e9-55f9ed8c-5772-440c-a813-20c1940e72d8-000000@us-east-2.amazonses.com> Message-ID: Actually, your alex is /too/ new. See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4657. If you take the latest master, it will contain that, and your problem will be fixed. On 12/23/20 2:10 PM, Richard Eisenberg wrote: > Without having particular knowledge about this specific error: try > upgrading `alex`, the tool that GHC uses to produce its lexer. It's > possible a newer version of that tool will fix this problem. > > Richard > >> On Dec 23, 2020, at 1:37 PM, Neophytos Michael > > wrote: >> >> I am having some trouble building ghc on ubuntu.  I have ghc 8.8.4 >> installed on the machine.  I pulled from the main repository and >> followed the instructions here: >> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian >> >> >> Building with: >> ./hadrian/build -j >> >> it builds for a long time until it finally fails with the message >> below.  I would appreciate some advice on how to fix this. >> >> Thank you, >> Neo >> >> =========================== >> Exit code: 1 >> Stderr and Stdout: >> _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3495:3: error: >>     Variable not in scope: int16ToInt# :: Int# -> Int# >>      | >> 3495 |   int16ToInt# >>      |   ^^^^^^^^^^^ >> >> _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3520:3: error: >>     Variable not in scope: int32ToInt# :: Int# -> Int# >>      | >> 3520 |   int32ToInt# >>      |   ^^^^^^^^^^^ >> =========================== >> On that line (in Lexer.hs) we see: >> >> #if __GLASGOW_HASKELL__ >= 901 >>   int16ToInt# >> #endif >>     (indexInt16OffAddr# arr off) >> #endif >> >> so we are in the "then" clause and somehow "int16ToInt#" is nowhere >> to be found. >> >> -- >> Neo >> >> _______________________________________________ >> 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 nmichael at gmail.com Thu Dec 24 12:10:32 2020 From: nmichael at gmail.com (Neophytos Michael) Date: Thu, 24 Dec 2020 14:10:32 +0200 Subject: Troubles when building ghc In-Reply-To: References: <010f0176910255e9-55f9ed8c-5772-440c-a813-20c1940e72d8-000000@us-east-2.amazonses.com> Message-ID: Thank you for that. After downgrading alex I was able to build ghc properly. By the way, is there a way from cabal to uninstall a package? I actually had both versions of alex on my machine but somehow ghc would always pick up the latest one. I couldn't find a way to uninstall alex, so I just gave up and removed the entire cabal directory and reinstalled everything (which fortunately wasn't much) plus the old version of alex. Neo On Wed, Dec 23, 2020 at 9:12 PM John Ericson wrote: > Actually, your alex is *too* new. See > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4657. If you take the > latest master, it will contain that, and your problem will be fixed. > On 12/23/20 2:10 PM, Richard Eisenberg wrote: > > Without having particular knowledge about this specific error: try > upgrading `alex`, the tool that GHC uses to produce its lexer. It's > possible a newer version of that tool will fix this problem. > > Richard > > On Dec 23, 2020, at 1:37 PM, Neophytos Michael wrote: > > I am having some trouble building ghc on ubuntu. I have ghc 8.8.4 > installed on the machine. I pulled from the main repository and followed > the instructions here: > https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian > > Building with: > ./hadrian/build -j > > it builds for a long time until it finally fails with the message below. > I would appreciate some advice on how to fix this. > > Thank you, > Neo > > =========================== > Exit code: 1 > Stderr and Stdout: > _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3495:3: error: > Variable not in scope: int16ToInt# :: Int# -> Int# > | > 3495 | int16ToInt# > | ^^^^^^^^^^^ > > _build/stage1/compiler/build/GHC/Parser/Lexer.hs:3520:3: error: > Variable not in scope: int32ToInt# :: Int# -> Int# > | > 3520 | int32ToInt# > | ^^^^^^^^^^^ > =========================== > On that line (in Lexer.hs) we see: > > #if __GLASGOW_HASKELL__ >= 901 > int16ToInt# > #endif > (indexInt16OffAddr# arr off) > #endif > > so we are in the "then" clause and somehow "int16ToInt#" is nowhere to be > found. > > -- > Neo > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > -- Neophytos -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Thu Dec 24 16:37:25 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 24 Dec 2020 16:37:25 +0000 Subject: can't get raw logs -- server down? Message-ID: <010f0176959cbbaa-b258f8cb-46ee-40b6-a052-c9ed1cfe588e-000000@us-east-2.amazonses.com> Hi devs, I have a failing CI run at https://gitlab.haskell.org/ghc/ghc/-/jobs/533674 . I can't repro the problem locally, so I wanted to see the raw log. But clicking the raw log button (leading to https://gitlab.haskell.org/ghc/ghc/-/jobs/533674/raw ) gets nothing. It looks like a server is down. Help? Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Thu Dec 24 17:18:57 2020 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Thu, 24 Dec 2020 18:18:57 +0100 Subject: can't get raw logs -- server down? In-Reply-To: <010f0176959cbbaa-b258f8cb-46ee-40b6-a052-c9ed1cfe588e-000000@us-east-2.amazonses.com> References: <010f0176959cbbaa-b258f8cb-46ee-40b6-a052-c9ed1cfe588e-000000@us-east-2.amazonses.com> Message-ID: Hi Richard, I can access the log just fine. In case you still can't, here it is (at least for a few days): https://1drv.ms/u/s!AvWV1ZpCBdeckIF5-Stx7QZ0gWiUKg?e=NYjO2H Hope that helps. Merry Christmas :) Sebastian Am Do., 24. Dez. 2020 um 17:38 Uhr schrieb Richard Eisenberg < rae at richarde.dev>: > Hi devs, > > I have a failing CI run at > https://gitlab.haskell.org/ghc/ghc/-/jobs/533674. I can't repro the > problem locally, so I wanted to see the raw log. But clicking the raw log > button (leading to https://gitlab.haskell.org/ghc/ghc/-/jobs/533674/raw) > gets nothing. It looks like a server is down. > > Help? > > Thanks! > Richard > _______________________________________________ > 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 rae at richarde.dev Thu Dec 24 18:39:47 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 24 Dec 2020 18:39:47 +0000 Subject: can't get raw logs -- server down? In-Reply-To: References: <010f0176959cbbaa-b258f8cb-46ee-40b6-a052-c9ed1cfe588e-000000@us-east-2.amazonses.com> Message-ID: <010f0176960cc32c-4f63954c-3789-4355-ab7e-f49735f89bf3-000000@us-east-2.amazonses.com> Thanks! Still can't access the log directly -- very bizarre. But your sharing revealed that I can, in fact, repro locally -- it's just that the error is inscrutable. At least I know where to investigate next. Merry Christmas, all! Richard > On Dec 24, 2020, at 12:18 PM, Sebastian Graf wrote: > > Hi Richard, > > I can access the log just fine. In case you still can't, here it is (at least for a few days): https://1drv.ms/u/s!AvWV1ZpCBdeckIF5-Stx7QZ0gWiUKg?e=NYjO2H > > Hope that helps. > > Merry Christmas :) > Sebastian > > Am Do., 24. Dez. 2020 um 17:38 Uhr schrieb Richard Eisenberg >: > Hi devs, > > I have a failing CI run at https://gitlab.haskell.org/ghc/ghc/-/jobs/533674 . I can't repro the problem locally, so I wanted to see the raw log. But clicking the raw log button (leading to https://gitlab.haskell.org/ghc/ghc/-/jobs/533674/raw ) gets nothing. It looks like a server is down. > > Help? > > Thanks! > Richard > _______________________________________________ > 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 ben at well-typed.com Wed Dec 30 15:16:33 2020 From: ben at well-typed.com (Ben Gamari) Date: Wed, 30 Dec 2020 10:16:33 -0500 Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-rc1 released Message-ID: <878s9fs4s2.fsf@smart-cactus.org> Hello all, The GHC team is very pleased to announce the availability of the first release candidate of GHC 9.0.1 series. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/9.0.1-rc1/ This release candidate comes quite a bit later than expected after difficulty finding a performance neutral fix for a critical soundness bug, #17760. See [1] for details on the solution, particularly if you are a library maintainer currently using the touch# primop or withForeignPtr. Nevertheless, this release has nevertheless seen a considerable amount of testing and consequently we hope that this should be the last pre-release before the final release. In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new features: * A first cut of the new LinearTypes language extension [2], allowing use of linear function syntax and linear record fields. * A new bignum library (ghc-bignum), allowing GHC to be more easily used with integer libraries other than GMP. * Improvements in code generation, resulting in considerable performance improvements in some programs. * Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time. * Implementation of the "simplified subsumption" proposal [3] simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2. * Implementation of the QualifiedDo extension [4], allowing more convenient overloading of `do` syntax. * Improvements in compilation time. And many more. See the release notes [5] for a full accounting of the changes in this release. As always, do test this release and open tickets for whatever issues you encounter. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.0#ghc-prim-07 [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst [3] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst [4] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst [5] https://downloads.haskell.org/ghc/9.0.1-rc1/docs/html/users_guide/9.0.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: