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: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
Message-ID: <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>

> 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 <rae at richarde.dev> 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 <b at chreekat.net> 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
> > <carter.schonwald at gmail.com> 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 <rae at richarde.dev>
> 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 <b at chreekat.net> 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 <rae at richarde.dev> 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 <b at chreekat.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/ad7d4141/attachment.html>

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: <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.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 <b at chreekat.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/788a401b/attachment.html>

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: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>
 <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com>
Message-ID: <CAH9BU=zZ11=j0u9tQgYFADDbHTLVmQXXxeHrz8Q0Yz8XFCkgeQ@mail.gmail.com>

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 <rae at richarde.dev> skrev:

>
>
> On Dec 3, 2020, at 10:23 AM, Bryan Richter <b at chreekat.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/35cbe076/attachment.html>

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: <CAH9BU=zZ11=j0u9tQgYFADDbHTLVmQXXxeHrz8Q0Yz8XFCkgeQ@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>
 <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com>
 <CAH9BU=zZ11=j0u9tQgYFADDbHTLVmQXXxeHrz8Q0Yz8XFCkgeQ@mail.gmail.com>
Message-ID: <CAGL=qfG+0KOL+vFm54atThDWH68VCYN7wmc0-JJ-r-X9GtEi9g@mail.gmail.com>

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 <b at chreekat.net> 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 <rae at richarde.dev> skrev:
>
>>
>>
>> On Dec 3, 2020, at 10:23 AM, Bryan Richter <b at chreekat.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/b1f178e1/attachment.html>

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: <CAH9BU=zZ11=j0u9tQgYFADDbHTLVmQXXxeHrz8Q0Yz8XFCkgeQ@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>
 <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com>
 <CAH9BU=zZ11=j0u9tQgYFADDbHTLVmQXXxeHrz8Q0Yz8XFCkgeQ@mail.gmail.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 <b at chreekat.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/1fa35ca5/attachment.html>

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: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.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 <b at chreekat.net> 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: <CAGL=qfG+0KOL+vFm54atThDWH68VCYN7wmc0-JJ-r-X9GtEi9g@mail.gmail.com>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>
 <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com>
 <CAH9BU=zZ11=j0u9tQgYFADDbHTLVmQXXxeHrz8Q0Yz8XFCkgeQ@mail.gmail.com>
 <CAGL=qfG+0KOL+vFm54atThDWH68VCYN7wmc0-JJ-r-X9GtEi9g@mail.gmail.com>
Message-ID: <d285f81f-7eca-7d69-9bf4-5bb92b668fed@haskus.fr>

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 <b at chreekat.net 
> <mailto:b at chreekat.net>> 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 <rae at richarde.dev
>     <mailto:rae at richarde.dev>> skrev:
>
>
>
>>         On Dec 3, 2020, at 10:23 AM, Bryan Richter <b at chreekat.net
>>         <mailto:b at chreekat.net>> 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 <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/e7f5d350/attachment.html>

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: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>
 <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com>
 <6ed95415-867a-4eae-9050-8b7b844e85cc@www.fastmail.com>
Message-ID: <CAH9BU=xcFhH6TqDH0SGNkmO9Wk3c12ZvHuhF3MQx8=ziGBDyuQ@mail.gmail.com>

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 <eric at seidel.io> 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 <b at chreekat.net> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/d550d378/attachment.html>

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: <d285f81f-7eca-7d69-9bf4-5bb92b668fed@haskus.fr>
References: <CAH9BU=w30rw0XuzcG4jY36g4JaWiG16P6cdjX7ecHYbphhVfyA@mail.gmail.com>
 <010f0175d69a270c-70e38bb4-60cc-477c-be61-04d6e30524f6-000000@us-east-2.amazonses.com>
 <CAH9BU=zO=v5vLM8-0LVtROiFu1k8hd6FqjwBKX6XRCLnOmvXOw@mail.gmail.com>
 <010f0175dc7ad52a-504503b4-8657-4b2a-9d86-383bbe59c7d9-000000@us-east-2.amazonses.com>
 <CAGK9nurcVKGoXaTWaxh-abyQEH3O3fUYULo9PPfb-76DAoGDjg@mail.gmail.com>
 <CAHYVw0xKJQYHNii0-O_Do6D0r_cS=Prjz-pr_-NPCr0Q+Bs78g@mail.gmail.com>
 <CAH9BU=wQtXNBL1OL4pqYJ8Y_bCOHW1vsmrMAdMz4QncMMo5tkQ@mail.gmail.com>
 <010f0175e7714b79-9e4f396f-5434-4b9f-a16a-dd5d037fd655-000000@us-east-2.amazonses.com>
 <CAH9BU=zg4Xu2oBsYnZsEOGY5WiZzsrSapU39sdRZER6iMKADyg@mail.gmail.com>
 <010f01762952240e-ac920655-87e2-400b-b0ab-787fb2022012-000000@us-east-2.amazonses.com>
 <CAH9BU=zZ11=j0u9tQgYFADDbHTLVmQXXxeHrz8Q0Yz8XFCkgeQ@mail.gmail.com>
 <CAGL=qfG+0KOL+vFm54atThDWH68VCYN7wmc0-JJ-r-X9GtEi9g@mail.gmail.com>
 <d285f81f-7eca-7d69-9bf4-5bb92b668fed@haskus.fr>
Message-ID: <CA+h2Lzmyw8p2ALdhj_fGS2GsJ_6mTSvwsUDZOm8pWSpWD6PJRw@mail.gmail.com>

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 <sylvain at haskus.fr> 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 <b at chreekat.net> 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 <rae at richarde.dev> skrev:
>>>
>>>
>>>
>>> On Dec 3, 2020, at 10:23 AM, Bryan Richter <b at chreekat.net> 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: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
 <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 <vladislav at serokell.io> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201203/ee7bb25b/attachment-0001.html>

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: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
 <87o8nqfht7.fsf@smart-cactus.org>
 <92a1a86e-d48b-359a-9310-38fcb78ceaeb@obsidian.systems>
Message-ID: <CAGL=qfFA3=GO99M6T28Z0G0XDNOG4hFxX2uuurvy6RNFgeBsMQ@mail.gmail.com>

FWIW I have a parser-generator implementation here
https://github.com/simonmar/happy/pull/170

On Fri, Dec 4, 2020, 06:35 John Ericson <john.ericson at obsidian.systems>
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 <vladislav at serokell.io> <vladislav at serokell.io> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201204/09d92fdc/attachment.html>

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: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
References: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
Message-ID: <a2e1d02e-a560-f70d-f080-7a8766a4556b@iki.fi>

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: <a2e1d02e-a560-f70d-f080-7a8766a4556b@iki.fi>
References: <AF25BE4B-3E0C-468F-A673-D1D40CE64E38@serokell.io>
 <a2e1d02e-a560-f70d-f080-7a8766a4556b@iki.fi>
Message-ID: <f7f7ea55-6d95-a14c-53f5-aca498ff3422@obsidian.systems>

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: <CAEDGBqKii4i-kkMmFpz6=-ge61H6SSzTEE2LiyZmdrYAZTGWrg@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201207/0cbf4ba5/attachment.html>

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/ <https://haskell.foundation/executive-director>ed-job-description <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201208/75eb1867/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201209/f31a96ae/attachment.sig>

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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201210/690e47b3/attachment.sig>

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: <CAD34_kKnMwVmdKrnSg16bLV+w9FHniAFO57dT-B+SNDhvNH=bQ@mail.gmail.com>

No problem, thanks for the update Ben! Something to look forward to

On Thu, Dec 10, 2020, 00:11 Ben Gamari <ben at well-typed.com> wrote:

> Ben Gamari <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201210/93f47adc/attachment.html>

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: <CAAS+=P8WoJ8SJqwXzC06peGnaw1qPVVHxyb8T__DHyqRXvqXuQ@mail.gmail.com>

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
<https://gitlab.haskell.org/ghc/ghc/-/merge_requests/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 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4493> 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
<https://gitlab.haskell.org/ghc/ghc/-/issues/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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201215/0c8494f0/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201215/9160c195/attachment.sig>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201219/ab749664/attachment.sig>

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: <CAMsAzy-dso2eaS-d5ZSBGZ=fzKr5M=a_ZWU26rhPiO8d0qi_1Q@mail.gmail.com>

On Sat, Dec 19, 2020 at 7:23 PM Ben Gamari <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201220/39bee2b1/attachment.html>

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: <CAMsAzy-dso2eaS-d5ZSBGZ=fzKr5M=a_ZWU26rhPiO8d0qi_1Q@mail.gmail.com>
References: <87wnxdfht8.fsf@smart-cactus.org>
 <CAMsAzy-dso2eaS-d5ZSBGZ=fzKr5M=a_ZWU26rhPiO8d0qi_1Q@mail.gmail.com>
Message-ID: <87tusgfkwr.fsf@smart-cactus.org>

Shayne Fletcher <shayne.fletcher.50 at gmail.com> writes:

> On Sat, Dec 19, 2020 at 7:23 PM Ben Gamari <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201220/895f787c/attachment.sig>

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: <CABHktDWQpO6kkKXUu-wLUsRe6p78EQNwV=-c0kCNy8UL8WeCGg@mail.gmail.com>

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 <ben at well-typed.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201220/b5c7426d/attachment.html>

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: <CAM171rKra3_3251cQn=5omV_WZqD6jDGV2Dva59ycYsQswtHoA@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201223/f8a39c38/attachment.html>

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: <CAM171rKra3_3251cQn=5omV_WZqD6jDGV2Dva59ycYsQswtHoA@mail.gmail.com>
References: <CAM171rKra3_3251cQn=5omV_WZqD6jDGV2Dva59ycYsQswtHoA@mail.gmail.com>
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 <nmichael at gmail.com> 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 <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201223/2ef098dc/attachment.html>

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: <CAM171rKra3_3251cQn=5omV_WZqD6jDGV2Dva59ycYsQswtHoA@mail.gmail.com>
 <010f0176910255e9-55f9ed8c-5772-440c-a813-20c1940e72d8-000000@us-east-2.amazonses.com>
Message-ID: <db1d46a9-7270-e69a-9d25-b79ca20af29a@obsidian.systems>

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 <nmichael at gmail.com 
>> <mailto:nmichael at gmail.com>> 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 
>> <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 <mailto: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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201223/3330cfbe/attachment.html>

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: <db1d46a9-7270-e69a-9d25-b79ca20af29a@obsidian.systems>
References: <CAM171rKra3_3251cQn=5omV_WZqD6jDGV2Dva59ycYsQswtHoA@mail.gmail.com>
 <010f0176910255e9-55f9ed8c-5772-440c-a813-20c1940e72d8-000000@us-east-2.amazonses.com>
 <db1d46a9-7270-e69a-9d25-b79ca20af29a@obsidian.systems>
Message-ID: <CAM171rJB8bRaxK3GbVvmwoqhbEhHzsEKnDPaWeMvvf4M-7W1Rg@mail.gmail.com>

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 <john.ericson at obsidian.systems>
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 <nmichael at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201224/f37d95a3/attachment.html>

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 <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 <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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201224/118bc0e3/attachment.html>

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: <CAAS+=P8nm8swK+wZhBnjjVFa3quWfPOHn4EB7GCLd7hYZMZDNg@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201224/f2cff856/attachment.html>

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: <CAAS+=P8nm8swK+wZhBnjjVFa3quWfPOHn4EB7GCLd7hYZMZDNg@mail.gmail.com>
References: <010f0176959cbbaa-b258f8cb-46ee-40b6-a052-c9ed1cfe588e-000000@us-east-2.amazonses.com>
 <CAAS+=P8nm8swK+wZhBnjjVFa3quWfPOHn4EB7GCLd7hYZMZDNg@mail.gmail.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 <sgraf1337 at gmail.com> 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 <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 <mailto:rae at richarde.dev>>:
> Hi devs,
> 
> I have a failing CI run at https://gitlab.haskell.org/ghc/ghc/-/jobs/533674 <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 <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 <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs <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/20201224/ebf09af8/attachment.html>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20201230/d9a40de6/attachment.sig>