From moritz.angermann at gmail.com  Tue Sep  1 02:52:31 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 1 Sep 2020 10:52:31 +0800
Subject: Creative ideas on how to debug heap corruption
In-Reply-To: <CANjChEpNOXnPeW=kfR2Q+ER2oRiFtft3gkykT2++NGuiH9DJLg@mail.gmail.com>
References: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
 <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
 <CANjChEoY=Y1XYV9jNkb+qn3ypV3vrHWu9dtChgDmA-wC8D-HxA@mail.gmail.com>
 <CAB-d4A7fqSGWir8YtPnsUOWDLruvBmhV9rZ3r8uNRKy5vhg5FQ@mail.gmail.com>
 <CAB-d4A755GVo1jUU=Zo+SitMVV=2r16SNQ-81hiYEgoK-zP+Uw@mail.gmail.com>
 <CANjChEpNOXnPeW=kfR2Q+ER2oRiFtft3gkykT2++NGuiH9DJLg@mail.gmail.com>
Message-ID: <CAKfdd-x07-6F-=2U3j5AtePc_VeU3WCn8dF0sxf2dbja-ZvBRA@mail.gmail.com>

Thanks everyone. I have indeed been trying to get somewhere with sanity
checking. That used to help quite a bit for the deadstripping stuff that
happened on iOS a long time ago, but that was also much more deterministic.
Maybe I'll try to see if running it through qemu will give me some more
determinism. That at least gives somewhat predictable allocations. It could
still end up being some annoying memory ordering issues, the llvm backend
just managed to happen to not run into by luck, or optimisation passes.

On Mon, Aug 31, 2020 at 10:29 PM Csaba Hruska <csaba.hruska at gmail.com>
wrote:

> Fuzzing:
>
>    1. generate simple random stg programs
>    2. compile and run with RTS sanity checking enabled
>    3. compare the program result between different backends
>
> The fuzzer should cover all codegen cases and all code in RTS. Maybe this
> could be checked by the existing tools.
>
> On Mon, Aug 31, 2020 at 4:19 PM George Colpitts <george.colpitts at gmail.com>
> wrote:
>
>> +Moritz
>>
>> On Mon, Aug 31, 2020 at 11:17 AM George Colpitts <
>> george.colpitts at gmail.com> wrote:
>>
>>> I assume you're familiar with the following from
>>> https://www.aosabook.org/en/ghc.html and that this facility is still
>>> there. Just in case you are not:
>>>
>>> So, the debug RTS has an optional mode that we call *sanity checking*.
>>> Sanity checking enables all kinds of expensive assertions, and can make the
>>> program run many times more slowly. In particular, sanity checking runs a
>>> full scan of the heap to check for dangling pointers (amongst other
>>> things), before *and* after every GC. The first job when investigating
>>> a runtime crash is to run the program with sanity checking turned on;
>>> sometimes this will catch the invariant violation well before the program
>>> actually crashes.
>>>
>>>
>>> On Mon, Aug 31, 2020 at 11:08 AM Csaba Hruska <csaba.hruska at gmail.com>
>>> wrote:
>>>
>>>> Dump the whole heap into file during GC traversal or taking the whole
>>>> allocated area. hmm, maybe this is the same as core dump.
>>>>
>>>> On Mon, Aug 31, 2020 at 11:00 AM Ben Lippmeier <benl at ouroborus.net>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> > On 31 Aug 2020, at 5:54 pm, Moritz Angermann <
>>>>> moritz.angermann at gmail.com> wrote:
>>>>> >
>>>>> > If anyone has some create ideas, I'd love to hear them.  I've been
>>>>> wondering
>>>>> > if just logging allocations (offset, range, type) would help
>>>>> figuring out what we
>>>>> > expected to be there; and then maybe try to break on the allocation,
>>>>> (and
>>>>> > subsequent writes).
>>>>> >
>>>>> > I'm sure some have been down this road before.
>>>>>
>>>>> Force a GC before every allocation, and make the GC check the validity
>>>>> of the objects before it moves anything. I think this used to be possible
>>>>> by compiling the runtime system in debug mode.
>>>>>
>>>>> The usual pain of heap corruption is that once the heap is corrupted
>>>>> it may be several GC cycles before you get the actual crash, and in the
>>>>> meantime the objects have all been moved around. The GC walks over all the
>>>>> objects by nature, so get it to validate the heap every time it does, then
>>>>> force it to run as often as you possibly can.
>>>>>
>>>>> A user space approach is to use a library like vacuum or packman that
>>>>> also walks over the heap objects directly.
>>>>>
>>>>> http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
>>>>> https://hackage.haskell.org/package/packman
>>>>>
>>>>> Ben.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20200901/67993cdd/attachment.html>

From sgraf1337 at gmail.com  Tue Sep  1 08:11:59 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Tue, 1 Sep 2020 10:11:59 +0200
Subject: COMPLETE pragmas
In-Reply-To: <CAJumaK8ARUvkU5R7sWHQgAoPHPreE29DwNoxrLs7xi9nU1hzpw@mail.gmail.com>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
 <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
 <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>
 <CAJumaK8ARUvkU5R7sWHQgAoPHPreE29DwNoxrLs7xi9nU1hzpw@mail.gmail.com>
Message-ID: <CAAS+=P__xdryerMhBL3saBpoihRG6skBP5DE+hXkOcC6HSbv9Q@mail.gmail.com>

Hi Edward,

I'd expect (1) to work after fixing #14422/#18276.
(3) might have been https://gitlab.haskell.org/ghc/ghc/-/issues/16682, so
it should be fixed nowadays.
(2) is a neat idea, but requires a GHC proposal I'm not currently willing
to get into. I can also see a design discussion around allowing arbitrary
"formulas" (e.g., not only what is effectively CNF).
A big bonus of your design is that it's really easy to integrate into the
current implementation, which is what I'd gladly do in case such a proposal
would get accepted.

Cheers
Sebastian

Am Di., 1. Sept. 2020 um 00:26 Uhr schrieb Edward Kmett <ekmett at gmail.com>:

> I'd be over the moon with happiness if I could hang COMPLETE pragmas on
> polymorphic types.
>
> I have 3 major issues with COMPLETE as it exists.
>
> 1.) Is what is mentioned here:
>
> Examples for me come up when trying to build a completely unboxed 'linear'
> library using backpack. In the end I want/need to supply a pattern synonym
> that works over, say, all the 2d vector types, extracting their elements,
> but right now I just get spammed by incomplete coverage warnings.
>
> type family Elem t :: Type
> class D2 where
>   _V2 :: Iso' t (Elem t, Elem t)
>
> pattern V2 :: D2 t => Elem t -> Elem t -> t
> pattern V2 a b <- (view _V2 -> (a,b)) where
>   V2 a b = review _V2 (a,b)
>
> There is no way to hang a COMPLETE pragma on that.
>
> 2.) Another scenario that I'd really love to see supported with COMPLETE
> pragmas is a way to use | notation with them like you can with MINIMAL
> pragmas.
>
> If you make smart constructors for a dozen constructors in your term type
> (don't judge me!), you wind up needing 2^12 COMPLETE pragmas to describe
> all the ways you might mix regular and start constructors today.
>
> {# COMPLETE (Lam | LAM), (Var | VAR), ... #-}
>
> would let you get away with a single such definition. This comes up when
> you have some kind of monoid that acts on terms and you want to push it
> down through
> the syntax tree invisibly to the user. Explicit substitutions, shifts in
> position in response to source code edits, etc.
>
> 3.) I had one other major usecase where I failed to be able to use a
> COMPLETE pragma:
>
> type Option a = (# a | (##) #)
>
> pattern Some :: a -> Option a
> pattern Some a = (# a | #)
>
> pattern None :: Option a
> pattern None = (# | (##) #)
>
> {-# COMPLETE Some, None #-}
>
> These worked _within_ a module, but was forgotten across module
> boundaries, which forced me to rather drastically change the module
> structure of a package, but it sounds a lot like the issue being discussed.
> No types to hang it on in the interface file. With the ability to define
> unlifted newtypes I guess this last one is less of a concern now?
>
> -Edward
>
> On Mon, Aug 31, 2020 at 2:29 PM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> Hooray Sebastian!
>>
>> Somehow, I knew cluing you into this conundrum would help find a
>> solution. The approach you describe sounds quite plausible.
>>
>> Yet: types *do* matter, of course. So, I suppose the trick is this: have
>> the COMPLETE sets operate independent of types, but then use types in the
>> PM-checker when determining impossible cases? And, about your idea for
>> having pattern synonyms store pointers to their COMPLETE sets: I think data
>> constructors can also participate. But maybe there is always at least one
>> pattern synonym (which would be a reasonable restriction), so I guess you
>> can look at the pattern-match as a whole and use the pattern synonym to
>> find the relevant COMPLETE set(s).
>>
>> Thanks for taking a look!
>> Richard
>>
>> On Aug 31, 2020, at 4:23 PM, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>>
>> Hi Richard,
>>
>> Am Mo., 31. Aug. 2020 um 21:30 Uhr schrieb Richard Eisenberg <
>> rae at richarde.dev>:
>>
>>> Hi Sebastian,
>>>
>>> I enjoyed your presentation last week at ICFP!
>>>
>>
>> Thank you :) I'm glad you liked it!
>>
>> This thread (
>>> https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms)
>>> played out before you became so interested in pattern-match coverage. I'd
>>> be curious for your thoughts there -- do you agree with the conclusions in
>>> the thread?
>>>
>>
>> I vaguely remember reading this thread. As you write there
>> <https://ghc-devs.haskell.narkive.com/NXBBDXg1/suppressing-false-incomplete-pattern-matching-warnings-for-polymorphic-pattern-synonyms#post9>
>>
>> And, while I know it doesn't work today, what's wrong (in theory) with
>>>
>>> {-# COMPLETE LL #-}
>>>
>>> No types! (That's a rare thing for me to extol...)
>>>
>>> I feel I must be missing something here.
>>>
>>
>> Without reading the whole thread, I think that solution is very possible.
>> The thread goes on to state that we currently attach COMPLETE sets to type
>> constructors, but that is only an implementational thing. I asked Matt (who
>> implemented it) somewhere and he said the only reason to attach it to type
>> constructors was because it was the easiest way to implement serialisation
>> to interface files.
>>
>> The thread also mentions that type-directed works better for the
>> pattern-match checker. In fact I disagree; we have to thin out COMPLETE
>> sets all the time anyway when new type evidence comes up, for example. It's
>> quite a hassle to find all the COMPLETE sets of the type constructors a
>> given type can be "represented" (I mean equality modulo type family
>> reductions here) as. I'm pretty sure it's broken in multiple ways, as
>> #18276 <https://gitlab.haskell.org/ghc/ghc/-/issues/18276> points out.
>>
>> Disregarding a bit of busy work for implementing serialisation to
>> interface files, it's probably far simpler to give each COMPLETE set a
>> Name/Unique and refer to them from the pattern synonyms that mention them
>> (we'd have to get creative for orphans, though). The relation is quite like
>> between a type class instance and the type in its head. A more worked
>> example is here:
>> https://gitlab.haskell.org/ghc/ghc/-/issues/18277#note_287827
>>
>> So, it's on my longer term TODO list to fix this.
>>
>>
>>> My motivation for asking is https://github.com/conal/linalg/pull/54
>>> (you don't need to read the whole thing), which can be boiled down to a
>>> request for a COMPLETE pragma that works at a polymorphic result type. (Or
>>> a COMPLETE pragma written in a module that is not the defining module for a
>>> pattern synonym.) https://gitlab.haskell.org/ghc/ghc/-/issues/14422
>>> describes a similar, but even more challenging scenario.
>>>
>>
>> I'll answer in the thread. (Oh, you also found #14422.) I think the
>> approach above will also fix #14422.
>>
>>>
>>> Do you see any ways forward here?
>>>
>> .
>>
>>>
>>> Thanks!
>>> Richard
>>
>>
>> Maybe I'll give it a try tomorrow.
>>
>>
>> _______________________________________________
>> 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/20200901/18426c27/attachment-0001.html>

From mail at joachim-breitner.de  Tue Sep  1 20:08:22 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 01 Sep 2020 22:08:22 +0200
Subject: COMPLETE pragmas
In-Reply-To: <CAAS+=P__xdryerMhBL3saBpoihRG6skBP5DE+hXkOcC6HSbv9Q@mail.gmail.com>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
 <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
 <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>
 <CAJumaK8ARUvkU5R7sWHQgAoPHPreE29DwNoxrLs7xi9nU1hzpw@mail.gmail.com>
 <CAAS+=P__xdryerMhBL3saBpoihRG6skBP5DE+hXkOcC6HSbv9Q@mail.gmail.com>
Message-ID: <788e388ef5e231e22a945c84748043c28ba8d493.camel@joachim-breitner.de>

Am Dienstag, den 01.09.2020, 10:11 +0200 schrieb Sebastian Graf:
> > 2.) Another scenario that I'd really love to see supported with
> > COMPLETE pragmas is a way to use | notation with them like you can
> > with MINIMAL pragmas.
> 
> (2) is a neat idea, but requires a GHC proposal I'm not currently
> willing to get into. I can also see a design discussion around
> allowing arbitrary "formulas" (e.g., not only what is effectively
> CNF).
>
> A big bonus of your design is that it's really easy to integrate into
> the current implementation, which is what I'd gladly do in case such
> a proposal would get accepted.

in the original ticket where a COMPLETE pragma was suggested (
https://gitlab.haskell.org/ghc/ghc/-/issues/8779) the ability to
specify arbitrary boolean formulas was already present:

“So here is what I think might work well, inspired by the new MINIMAL
pragma: … The syntax is essentially the same as for MINIMAL, i.e. a
boolean formula, with constructors and pattern synonyms as atoms. In
this case”

So one _could_ say that this doesn’t need a proposal, because it would
just be the implementation finishing the original task ;-)


Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Tue Sep  1 22:36:56 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 1 Sep 2020 22:36:56 +0000
Subject: GHC Logo
In-Reply-To: <87bljaa1f1.fsf@smart-cactus.org>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
 <87mu2vapc9.fsf@smart-cactus.org>
 <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>
 <87ft8madu1.fsf@smart-cactus.org>
 <CDFAC7D2-07FE-4BB4-AFDA-1E637ECACB9F@inconsistent.nl>
 <87bljaa1f1.fsf@smart-cactus.org>
Message-ID: <010f01744bd0e9be-f906f935-2ac1-4bd9-a730-a0c3724e765b-000000@us-east-2.amazonses.com>

Late to the party here, but I'm wondering whether we can enlist someone with graphic design experience to create a more iconic logo for the compiler. I use the word "iconic" deliberately: it should both be recognizable, and in the shape of an icon (that is, more square). The Haskell logo does this wonderfully, but I think Ben's proposal just appends GHC to that.

My own preference would be to retain a connection with the Haskell logo (as Ben's submission does), but that needn't be a hard requirement.

Thanks,
Richard

> On Aug 16, 2020, at 2:30 PM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Merijn Verstraaten <merijn at inconsistent.nl> writes:
> 
>>> On 16 Aug 2020, at 16:02, Ben Gamari <ben at well-typed.com> wrote:
>>> 
>>> Carter Schonwald <carter.schonwald at gmail.com> writes:
>>> 
>>>> I def like the serif / times new Roman version
>>>> 
>>> I'm not aware of a serif version and in general I would be hesitant to
>>> introduce one given that:
>> 
>> The one you send out renders using a serif font for GHC on my system (and, presumably, Carter's).
>> 
> Indeed, sounds like a missing font. The typeface used is Cantarell,
> which is certainly a sans-serif face. You will find a version on the
> Wiki which has had the text projected to paths.
> 
> Cheers,
> 
> - Ben
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From dyaitskov at gmail.com  Tue Sep  1 23:50:50 2020
From: dyaitskov at gmail.com (Daneel Yaitskov)
Date: Tue, 1 Sep 2020 18:50:50 -0500
Subject: GHC Logo
In-Reply-To: <87zh6w9fxf.fsf@smart-cactus.org>
References: <87zh6w9fxf.fsf@smart-cactus.org>
Message-ID: <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>

Hi,

Is it a contest for picking up a new logo?
As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
means Haskell.

So logo should be GλC.

Best Regards,
Daniil.

On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com> wrote:

> Hi everyone,
>
> Recently a sponsor asked for a logo for our project. As far as I know,
> GHC doesn't really have a consistent logo; the closest that we have had
> is the stylized "GHC" on the top of ghc.haskell.org.
>
> To accomodate the request, I took a few minutes and reworked the
> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
> couldn't positively identify the typeface used for the "Haskell" text,
> but I believe that the extra-bold Cantarell face that I chose in the GHC
> variant has a similar feel to the Haskell logo and is free to use.
>
> I've posted the logo on the Wiki for future reference [1]. Feedback is
> very much welcome.
>
> Cheers,
>
> - Ben
>
>
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
> _______________________________________________
> 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/20200901/f31c6164/attachment.html>

From carter.schonwald at gmail.com  Wed Sep  2 00:42:23 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 1 Sep 2020 20:42:23 -0400
Subject: GHC Logo
In-Reply-To: <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
Message-ID: <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>

Ben, what if we have someone draw a cartoony version of your box turtle? i
feel like that would be a pretty cute logo! totally ahistorical, but would
certainly be cute!

On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com> wrote:

> Hi,
>
> Is it a contest for picking up a new logo?
> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
> means Haskell.
>
> So logo should be GλC.
>
> Best Regards,
> Daniil.
>
> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com> wrote:
>
>> Hi everyone,
>>
>> Recently a sponsor asked for a logo for our project. As far as I know,
>> GHC doesn't really have a consistent logo; the closest that we have had
>> is the stylized "GHC" on the top of ghc.haskell.org.
>>
>> To accomodate the request, I took a few minutes and reworked the
>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>> couldn't positively identify the typeface used for the "Haskell" text,
>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>> variant has a similar feel to the Haskell logo and is free to use.
>>
>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>> very much welcome.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>>
>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>> _______________________________________________
>> 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/20200901/6e753c84/attachment.html>

From arnaud.spiwack at tweag.io  Wed Sep  2 13:39:52 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 2 Sep 2020 15:39:52 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>

> I admit I don't feel as strongly any more. My argument in that thread was
> from the standpoint of a language designer: there is really no reason, a
> priori, for an unboxed-tuple binding to be strict. What controls strictness
> is whether the bound variables are of unlifted type. However, I'm currently
> in more sympathy with language users, who (for whatever reason) seem to
> think that bindings with #s in them should be strict. (I have this
> intuition myself, even though it's not quite warranted on technical
> grounds.)
>

A middle ground could be to not allow unbanged patterns for unboxed tuples.
Since they currently exist, we could also simply emit a warning, saying:
“this is probably not what you want, do add an exclamation mark”.


> What do we think of
>
> pattern Unl x y = (# x, y #)
>
> ex1, ex2 :: ()
> ex1 = let Unl x y = Unl undefined undefined in ()
> ex2 = let Unl x y = undefined in ()
>
>
> ? Today, both ex1 and ex2 evaluate to (). If we were to change the
> specification here, would we consider any unlifted-type pattern (where the
> type of the pattern itself is unlifted, independent of the type of any of
> its bound variables) to be banged? Or would it be a super-special case for
> unboxed tuples?
>

Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know
what the semantics of these ought to be. It does look like an interesting
can of worms. How do they currently desugar?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200902/90829d28/attachment.html>

From rae at richarde.dev  Wed Sep  2 13:46:52 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 2 Sep 2020 13:46:52 +0000
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
Message-ID: <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>



> On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know what the semantics of these ought to be. It does look like an interesting can of worms. How do they currently desugar?

Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the pattern is an unlifter-var pattern and is strict. The pattern must be banged, unless the bound variable is not nested. This rule is consistent across all features.

This thread is suggesting to add a special case -- one that seems to match intuition, but it's still a special case. And my question is: should the special case be for unboxed tuples? or should the special case be for any pattern whose overall type is unlifted?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200902/0a3a5d21/attachment.html>

From rae at richarde.dev  Wed Sep  2 14:16:13 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 2 Sep 2020 14:16:13 +0000
Subject: GHC Logo
In-Reply-To: <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
Message-ID: <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>

I'm oddly drawn to the idea of a turtle -- except that turtles are slow. But animals are cute. Maybe something involving a fox, given that foxes can be clever? Octopuses are also known to be very clever, but maybe GitHub has octopuses covered.

> On Sep 1, 2020, at 8:42 PM, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> 
> Ben, what if we have someone draw a cartoony version of your box turtle? i feel like that would be a pretty cute logo! totally ahistorical, but would certainly be cute!
> 
> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com <mailto:dyaitskov at gmail.com>> wrote:
> Hi, 
> 
> Is it a contest for picking up a new logo?
> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here means Haskell.
> 
> So logo should be GλC.
> 
> Best Regards,
> Daniil.
> 
> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>> wrote:
> Hi everyone,
> 
> Recently a sponsor asked for a logo for our project. As far as I know,
> GHC doesn't really have a consistent logo; the closest that we have had
> is the stylized "GHC" on the top of ghc.haskell.org <http://ghc.haskell.org/>.
> 
> To accomodate the request, I took a few minutes and reworked the
> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
> couldn't positively identify the typeface used for the "Haskell" text,
> but I believe that the extra-bold Cantarell face that I chose in the GHC
> variant has a similar feel to the Haskell logo and is free to use.
> 
> I've posted the logo on the Wiki for future reference [1]. Feedback is
> very much welcome.
> 
> Cheers,
> 
> - Ben
> 
> 
> 
> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo <https://gitlab.haskell.org/ghc/ghc/-/wikis/logo>
> _______________________________________________
> 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 <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/20200902/899ecf9c/attachment.html>

From rae at richarde.dev  Wed Sep  2 14:37:40 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Wed, 2 Sep 2020 14:37:40 +0000
Subject: GHC Logo
In-Reply-To: <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
Message-ID: <010f01744f407ce3-26dfb6f8-0f86-45df-98e1-42eadbc357b7-000000@us-east-2.amazonses.com>

On Sep 2, 2020, someone wrote to me privately saying:

> I was thinking Cats for some reason.

Ooh. I'm picturing a cat with its tail wrapped around a lambda, or something like that. And Simon PJ does have a cat named Haskell who could perhaps be the model. :)

Richard

> On Sep 2, 2020, at 10:16 AM, Richard Eisenberg <rae at richarde.dev> wrote:
> 
> I'm oddly drawn to the idea of a turtle -- except that turtles are slow. But animals are cute. Maybe something involving a fox, given that foxes can be clever? Octopuses are also known to be very clever, but maybe GitHub has octopuses covered.
> 
>> On Sep 1, 2020, at 8:42 PM, Carter Schonwald <carter.schonwald at gmail.com <mailto:carter.schonwald at gmail.com>> wrote:
>> 
>> Ben, what if we have someone draw a cartoony version of your box turtle? i feel like that would be a pretty cute logo! totally ahistorical, but would certainly be cute!
>> 
>> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com <mailto:dyaitskov at gmail.com>> wrote:
>> Hi, 
>> 
>> Is it a contest for picking up a new logo?
>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here means Haskell.
>> 
>> So logo should be GλC.
>> 
>> Best Regards,
>> Daniil.
>> 
>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com <mailto:ben at well-typed.com>> wrote:
>> Hi everyone,
>> 
>> Recently a sponsor asked for a logo for our project. As far as I know,
>> GHC doesn't really have a consistent logo; the closest that we have had
>> is the stylized "GHC" on the top of ghc.haskell.org <http://ghc.haskell.org/>.
>> 
>> To accomodate the request, I took a few minutes and reworked the
>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>> couldn't positively identify the typeface used for the "Haskell" text,
>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>> variant has a similar feel to the Haskell logo and is free to use.
>> 
>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>> very much welcome.
>> 
>> Cheers,
>> 
>> - Ben
>> 
>> 
>> 
>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo <https://gitlab.haskell.org/ghc/ghc/-/wikis/logo>
>> _______________________________________________
>> 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 <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 <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/20200902/d8843b2f/attachment.html>

From fryguybob at gmail.com  Wed Sep  2 14:39:12 2020
From: fryguybob at gmail.com (Ryan Yates)
Date: Wed, 2 Sep 2020 10:39:12 -0400
Subject: GHC Logo
In-Reply-To: <010f01744f407ce3-26dfb6f8-0f86-45df-98e1-42eadbc357b7-000000@us-east-2.amazonses.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
 <010f01744f407ce3-26dfb6f8-0f86-45df-98e1-42eadbc357b7-000000@us-east-2.amazonses.com>
Message-ID: <CAO27hRqw-EiHe2pz55gm6cnNdK+n7h=3Z154REq1GTb+ycNSHQ@mail.gmail.com>

Cats are warm and fuzzy.

On Wed, Sep 2, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev> wrote:

> On Sep 2, 2020, someone wrote to me privately saying:
>
> > I was thinking Cats for some reason.
>
> Ooh. I'm picturing a cat with its tail wrapped around a lambda, or
> something like that. And Simon PJ does have a cat named Haskell who could
> perhaps be the model. :)
>
> Richard
>
> On Sep 2, 2020, at 10:16 AM, Richard Eisenberg <rae at richarde.dev> wrote:
>
> I'm oddly drawn to the idea of a turtle -- except that turtles are slow.
> But animals are cute. Maybe something involving a fox, given that foxes can
> be clever? Octopuses are also known to be very clever, but maybe GitHub has
> octopuses covered.
>
> On Sep 1, 2020, at 8:42 PM, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> Ben, what if we have someone draw a cartoony version of your box turtle? i
> feel like that would be a pretty cute logo! totally ahistorical, but would
> certainly be cute!
>
> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com>
> wrote:
>
>> Hi,
>>
>> Is it a contest for picking up a new logo?
>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
>> means Haskell.
>>
>> So logo should be GλC.
>>
>> Best Regards,
>> Daniil.
>>
>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com> wrote:
>>
>>> Hi everyone,
>>>
>>> Recently a sponsor asked for a logo for our project. As far as I know,
>>> GHC doesn't really have a consistent logo; the closest that we have had
>>> is the stylized "GHC" on the top of ghc.haskell.org.
>>>
>>> To accomodate the request, I took a few minutes and reworked the
>>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>>> couldn't positively identify the typeface used for the "Haskell" text,
>>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>>> variant has a similar feel to the Haskell logo and is free to use.
>>>
>>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>>> very much welcome.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>>
>>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>>> _______________________________________________
>>> 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/20200902/154b409a/attachment.html>

From b at chreekat.net  Wed Sep  2 14:46:44 2020
From: b at chreekat.net (Bryan Richter)
Date: Wed, 2 Sep 2020 17:46:44 +0300
Subject: GHC Logo
In-Reply-To: <CAO27hRqw-EiHe2pz55gm6cnNdK+n7h=3Z154REq1GTb+ycNSHQ@mail.gmail.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
 <010f01744f407ce3-26dfb6f8-0f86-45df-98e1-42eadbc357b7-000000@us-east-2.amazonses.com>
 <CAO27hRqw-EiHe2pz55gm6cnNdK+n7h=3Z154REq1GTb+ycNSHQ@mail.gmail.com>
Message-ID: <CAH9BU=xHzJZb9KMCTB2OUG3FLLEkiZ_hAOgsi+sQQQRfn13vhA@mail.gmail.com>

I have no idea who or where it came from, but I loved the owl from BayHac
2013. In my mind, it has always been the Haskell mascot (I was pretty new
to the community in 2013).

https://wiki.haskell.org/BayHac2013

[image: image.png]


On Wed, Sep 2, 2020 at 5:39 PM Ryan Yates <fryguybob at gmail.com> wrote:

> Cats are warm and fuzzy.
>
> On Wed, Sep 2, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> On Sep 2, 2020, someone wrote to me privately saying:
>>
>> > I was thinking Cats for some reason.
>>
>> Ooh. I'm picturing a cat with its tail wrapped around a lambda, or
>> something like that. And Simon PJ does have a cat named Haskell who could
>> perhaps be the model. :)
>>
>> Richard
>>
>> On Sep 2, 2020, at 10:16 AM, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>> I'm oddly drawn to the idea of a turtle -- except that turtles are slow.
>> But animals are cute. Maybe something involving a fox, given that foxes can
>> be clever? Octopuses are also known to be very clever, but maybe GitHub has
>> octopuses covered.
>>
>> On Sep 1, 2020, at 8:42 PM, Carter Schonwald <carter.schonwald at gmail.com>
>> wrote:
>>
>> Ben, what if we have someone draw a cartoony version of your box turtle?
>> i feel like that would be a pretty cute logo! totally ahistorical, but
>> would certainly be cute!
>>
>> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Is it a contest for picking up a new logo?
>>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
>>> means Haskell.
>>>
>>> So logo should be GλC.
>>>
>>> Best Regards,
>>> Daniil.
>>>
>>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Recently a sponsor asked for a logo for our project. As far as I know,
>>>> GHC doesn't really have a consistent logo; the closest that we have had
>>>> is the stylized "GHC" on the top of ghc.haskell.org.
>>>>
>>>> To accomodate the request, I took a few minutes and reworked the
>>>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>>>> couldn't positively identify the typeface used for the "Haskell" text,
>>>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>>>> variant has a similar feel to the Haskell logo and is free to use.
>>>>
>>>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>>>> very much welcome.
>>>>
>>>> Cheers,
>>>>
>>>> - Ben
>>>>
>>>>
>>>>
>>>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>>>> _______________________________________________
>>>> 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
>>
> _______________________________________________
> 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/20200902/106c6727/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32507 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200902/106c6727/attachment-0001.png>

From gergo at erdi.hu  Wed Sep  2 14:54:22 2020
From: gergo at erdi.hu (=?UTF-8?B?RHIuIMOJUkRJIEdlcmfFkQ==?=)
Date: Wed, 2 Sep 2020 22:54:22 +0800
Subject: GHC Logo
In-Reply-To: <010f01744f407ce3-26dfb6f8-0f86-45df-98e1-42eadbc357b7-000000@us-east-2.amazonses.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
 <010f01744f407ce3-26dfb6f8-0f86-45df-98e1-42eadbc357b7-000000@us-east-2.amazonses.com>
Message-ID: <CAO7EwMo0XhDVP67hs8ZP55VQWPvHDV9Z6dEq45FvetAgwstz8w@mail.gmail.com>

The Cat's name should be Hask.

On Wed, Sep 2, 2020, 22:39 Richard Eisenberg <rae at richarde.dev> wrote:

> On Sep 2, 2020, someone wrote to me privately saying:
>
> > I was thinking Cats for some reason.
>
> Ooh. I'm picturing a cat with its tail wrapped around a lambda, or
> something like that. And Simon PJ does have a cat named Haskell who could
> perhaps be the model. :)
>
> Richard
>
> On Sep 2, 2020, at 10:16 AM, Richard Eisenberg <rae at richarde.dev> wrote:
>
> I'm oddly drawn to the idea of a turtle -- except that turtles are slow.
> But animals are cute. Maybe something involving a fox, given that foxes can
> be clever? Octopuses are also known to be very clever, but maybe GitHub has
> octopuses covered.
>
> On Sep 1, 2020, at 8:42 PM, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> Ben, what if we have someone draw a cartoony version of your box turtle? i
> feel like that would be a pretty cute logo! totally ahistorical, but would
> certainly be cute!
>
> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com>
> wrote:
>
>> Hi,
>>
>> Is it a contest for picking up a new logo?
>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
>> means Haskell.
>>
>> So logo should be GλC.
>>
>> Best Regards,
>> Daniil.
>>
>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com> wrote:
>>
>>> Hi everyone,
>>>
>>> Recently a sponsor asked for a logo for our project. As far as I know,
>>> GHC doesn't really have a consistent logo; the closest that we have had
>>> is the stylized "GHC" on the top of ghc.haskell.org.
>>>
>>> To accomodate the request, I took a few minutes and reworked the
>>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>>> couldn't positively identify the typeface used for the "Haskell" text,
>>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>>> variant has a similar feel to the Haskell logo and is free to use.
>>>
>>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>>> very much welcome.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>>
>>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>>> _______________________________________________
>>> 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/20200902/b5d2a1cf/attachment.html>

From carter.schonwald at gmail.com  Wed Sep  2 15:03:08 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 2 Sep 2020 11:03:08 -0400
Subject: GHC Logo
In-Reply-To: <CAH9BU=xHzJZb9KMCTB2OUG3FLLEkiZ_hAOgsi+sQQQRfn13vhA@mail.gmail.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
 <010f01744f407ce3-26dfb6f8-0f86-45df-98e1-42eadbc357b7-000000@us-east-2.amazonses.com>
 <CAO27hRqw-EiHe2pz55gm6cnNdK+n7h=3Z154REq1GTb+ycNSHQ@mail.gmail.com>
 <CAH9BU=xHzJZb9KMCTB2OUG3FLLEkiZ_hAOgsi+sQQQRfn13vhA@mail.gmail.com>
Message-ID: <CAHYVw0yGzJOVZT+CxU5XPDFiRknvZYj50r9LrBgDLn5+bp5gjg@mail.gmail.com>

Mark lentzer (I’m almost certainly spelling his last name wrong)

On Wed, Sep 2, 2020 at 10:47 AM Bryan Richter <b at chreekat.net> wrote:

> I have no idea who or where it came from, but I loved the owl from BayHac
> 2013. In my mind, it has always been the Haskell mascot (I was pretty new
> to the community in 2013).
>
> https://wiki.haskell.org/BayHac2013
>
> [image: image.png]
>
>
> On Wed, Sep 2, 2020 at 5:39 PM Ryan Yates <fryguybob at gmail.com> wrote:
>
>> Cats are warm and fuzzy.
>>
>> On Wed, Sep 2, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
>> wrote:
>>
>>> On Sep 2, 2020, someone wrote to me privately saying:
>>>
>>> > I was thinking Cats for some reason.
>>>
>>> Ooh. I'm picturing a cat with its tail wrapped around a lambda, or
>>> something like that. And Simon PJ does have a cat named Haskell who could
>>> perhaps be the model. :)
>>>
>>> Richard
>>>
>>> On Sep 2, 2020, at 10:16 AM, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>> I'm oddly drawn to the idea of a turtle -- except that turtles are slow.
>>> But animals are cute. Maybe something involving a fox, given that foxes can
>>> be clever? Octopuses are also known to be very clever, but maybe GitHub has
>>> octopuses covered.
>>>
>>> On Sep 1, 2020, at 8:42 PM, Carter Schonwald <carter.schonwald at gmail.com>
>>> wrote:
>>>
>>> Ben, what if we have someone draw a cartoony version of your box turtle?
>>> i feel like that would be a pretty cute logo! totally ahistorical, but
>>> would certainly be cute!
>>>
>>> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Is it a contest for picking up a new logo?
>>>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
>>>> means Haskell.
>>>>
>>>> So logo should be GλC.
>>>>
>>>> Best Regards,
>>>> Daniil.
>>>>
>>>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Recently a sponsor asked for a logo for our project. As far as I know,
>>>>>
>>>>>
>>>>> GHC doesn't really have a consistent logo; the closest that we have had
>>>>>
>>>>>
>>>>> is the stylized "GHC" on the top of ghc.haskell.org.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> To accomodate the request, I took a few minutes and reworked the
>>>>>
>>>>>
>>>>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>>>>>
>>>>>
>>>>> couldn't positively identify the typeface used for the "Haskell" text,
>>>>>
>>>>>
>>>>> but I believe that the extra-bold Cantarell face that I chose in the
>>>>> GHC
>>>>>
>>>>>
>>>>> variant has a similar feel to the Haskell logo and is free to use.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>>>>>
>>>>>
>>>>> very much welcome.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> - Ben
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>>
>>>>> 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
>>>
>>>
>>>
>>
>> _______________________________________________
>>
>>
>> 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/20200902/a637aaf3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32507 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200902/a637aaf3/attachment.png>

From carter.schonwald at gmail.com  Wed Sep  2 15:04:08 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 2 Sep 2020 11:04:08 -0400
Subject: GHC Logo
In-Reply-To: <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
Message-ID: <CAHYVw0zd62=g+uQgCvvnQCK3UXM-YYZhtMUq4+dmanGdshhcYQ@mail.gmail.com>

Ghc is a turtle. So much super linearity in the code base and very much a
safety oriented tool ;)

On Wed, Sep 2, 2020 at 10:16 AM Richard Eisenberg <rae at richarde.dev> wrote:

> I'm oddly drawn to the idea of a turtle -- except that turtles are slow.
> But animals are cute. Maybe something involving a fox, given that foxes can
> be clever? Octopuses are also known to be very clever, but maybe GitHub has
> octopuses covered.
>
>
> On Sep 1, 2020, at 8:42 PM, Carter Schonwald <carter.schonwald at gmail.com>
> wrote:
>
> Ben, what if we have someone draw a cartoony version of your box turtle? i
> feel like that would be a pretty cute logo! totally ahistorical, but would
> certainly be cute!
>
> On Tue, Sep 1, 2020 at 7:51 PM Daneel Yaitskov <dyaitskov at gmail.com>
> wrote:
>
>> Hi,
>>
>> Is it a contest for picking up a new logo?
>> As for me logo "λ GHC" is redundant, because H stands for Haskell and λ here
>> means Haskell.
>>
>> So logo should be GλC.
>>
>> Best Regards,
>> Daniil.
>>
>> On Sat, Aug 15, 2020, 8:50 AM Ben Gamari <ben at well-typed.com> wrote:
>>
>>> Hi everyone,
>>>
>>>
>>>
>>>
>>>
>>> Recently a sponsor asked for a logo for our project. As far as I know,
>>>
>>>
>>> GHC doesn't really have a consistent logo; the closest that we have had
>>>
>>>
>>> is the stylized "GHC" on the top of ghc.haskell.org.
>>>
>>>
>>>
>>>
>>>
>>> To accomodate the request, I took a few minutes and reworked the
>>>
>>>
>>> typography of the Thompson-Wheeler Haskell logo for use by GHC. I
>>>
>>>
>>> couldn't positively identify the typeface used for the "Haskell" text,
>>>
>>>
>>> but I believe that the extra-bold Cantarell face that I chose in the GHC
>>>
>>>
>>> variant has a similar feel to the Haskell logo and is free to use.
>>>
>>>
>>>
>>>
>>>
>>> I've posted the logo on the Wiki for future reference [1]. Feedback is
>>>
>>>
>>> very much welcome.
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>>
>>> - Ben
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/logo
>>>
>>>
>>> _______________________________________________
>>>
>>>
>>> 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/20200902/8b724cb2/attachment.html>

From ben at well-typed.com  Wed Sep  2 15:47:45 2020
From: ben at well-typed.com (Ben Gamari)
Date: Wed, 02 Sep 2020 11:47:45 -0400
Subject: GHC Logo
In-Reply-To: <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
Message-ID: <87bliorxi9.fsf@smart-cactus.org>

Richard Eisenberg <rae at richarde.dev> writes:

> I'm oddly drawn to the idea of a turtle -- except that turtles are
> slow. But animals are cute. Maybe something involving a fox, given
> that foxes can be clever? Octopuses are also known to be very clever,
> but maybe GitHub has octopuses covered.
>
In general I'm rather neutral on the logo question. There is a fine line
between "juvenile" (which may detract from the project's credibility in
the eyes of some) and "cute" (which I think is universally a Good
Thing); the current rather boring logo was a quick attempt to satisfy
the need for some logo while recognizing that I lack the artistic
ability to walk that line. I don't think it's a bad logo but it's quite
dull and far from being a *good* logo. I do hope someone steps up to do
better.

Logos aside, I do feel the need to correct the record here: you
clearly have not seen how quickly a turtle can move when offered banana
or shrimp. They can be quite quick when suitably incentivized!

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/20200902/0f8e3d24/attachment.sig>

From ben at smart-cactus.org  Wed Sep  2 16:03:04 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 02 Sep 2020 12:03:04 -0400
Subject: HsPragTick
In-Reply-To: <CANma=H_x6rxLCmH+Cz1B3wAN-j-=oL_DPjmmgWhg2thJ-d9Uig@mail.gmail.com>
References: <CANma=H_x6rxLCmH+Cz1B3wAN-j-=oL_DPjmmgWhg2thJ-d9Uig@mail.gmail.com>
Message-ID: <878sdsrwsr.fsf@smart-cactus.org>

"Alan & Kim Zimmerman" <alan.zimm at gmail.com> writes:

> I am working through the API Annotations, and have come across HsPragTick.
>
> In source it appears as
>
>   c = {-# GENERATED "foobar" 1 : 2  -  3 :   4 #-} 0.00
>
> But it does not seem to be used anywhere. It is passed through for renaming
> and type checking, and Coverage.hs uses it as
>
> addTickHsExpr (HsPragE _ HsPragTick{} (L pos e0)) = do
>     e2 <- allocTickBox (ExpBox False) False False (locA pos) $
>                 addTickHsExpr e0
>     return $ unLoc e2
>
> So if it is used at all, the contents are ignored.
>
> Can it be removed?
>
I traced the pragma's addition back to 
d386e0d20c6953b7cba4d53538a1782c4aa9980d (way back in 2006!). It appears
that it was intended to be used by code generators for use in informing
the code coveraging checker about generated code provenance. When it was
added it used the pragma's "payload" fields as source location
information to build an "ExternalBox". However, it looks like this
constructor was dropped in 55a5d8d90280a611bafb659bc80778d3927a6bff [2]
(only a year later!).

At this point it seems like the pragma serves no useful purpose. Given
that it *also* is not documented, I think we should remove it. I have
opened #18639 to track this.

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/-/commit/d386e0d20c6953b7cba4d53538a1782c4aa9980d 
[2] https://gitlab.haskell.org/ghc/ghc/-/commit/55a5d8d90280a611bafb659bc80778d3927a6bff#a033dd77bd63482866f5d4f8ed130427c9000779_308_319
-------------- 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/20200902/2081af75/attachment.sig>

From John.Ericson at Obsidian.Systems  Wed Sep  2 16:07:50 2020
From: John.Ericson at Obsidian.Systems (John Cotton Ericson)
Date: Wed, 2 Sep 2020 12:07:50 -0400
Subject: GHC Logo
In-Reply-To: <87bliorxi9.fsf@smart-cactus.org>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
 <87bliorxi9.fsf@smart-cactus.org>
Message-ID: <15799004-4f66-9324-c250-36025e82c2e6@Obsidian.Systems>

Yeah I think the old "functional programming is slow" memes died off 
about when the rest of the industry went on its JavaScript bender, so I 
am not really worried about the negative connotations of turtles.

The positive connotations of turtles sounds very good to me. Besides safety,

  *   the longevity of at least giant tortoises also speaks to GHC's
    rare ability to stay at the vanguard of research while still being
    wildly used.
  * Their ability to walk and swim speaks to the diverse backends that
    can be attached to GHC (NCG, LLVM, GHCJS, Asterius, Clash's, etc.).
  * Even the fable, from which the slowness myth comes from I guess,
    goes well with "avoid success at all costs".

Conversely I am not a fan of choosing a Cat. I like Cats fine in real 
life, don't get be wrong, but Cats are so popular on the internet that 
this would be the the unmarked animal choice, with no clear connotations 
or memorability. I think that would be the juvenile choice, per Ben's 
slippery slope.

Foxes are nice, but I think Firefox has that for life.

Octopuses are alright. GitHub's Octocat doesn't doesn't pose nearly as 
much of a problem as Firefox for foxes. Still, while Octopuses are 
smart, they are usually solitary and mischievous. GHC is very much a 
long-term group effort, belying the solitary connotation, and I 
certainly hope any compiler I use isn't mischievous!

A turtle for a compiler is a bold choice that indicates our values, 
confidence that the performance of compiled code is immune to cheap 
derision, and humor.

John

P.S. The funny patterns on turtles' backs could be made of lambdas?...

P.P.S. and yes, if it does compel us to fix rampant list appending just 
so we're fast on all fronts, that would be nice too :).

On 9/2/20 11:47 AM, Ben Gamari wrote:
> Richard Eisenberg <rae at richarde.dev> writes:
>
>> I'm oddly drawn to the idea of a turtle -- except that turtles are
>> slow. But animals are cute. Maybe something involving a fox, given
>> that foxes can be clever? Octopuses are also known to be very clever,
>> but maybe GitHub has octopuses covered.
>>
> In general I'm rather neutral on the logo question. There is a fine line
> between "juvenile" (which may detract from the project's credibility in
> the eyes of some) and "cute" (which I think is universally a Good
> Thing); the current rather boring logo was a quick attempt to satisfy
> the need for some logo while recognizing that I lack the artistic
> ability to walk that line. I don't think it's a bad logo but it's quite
> dull and far from being a *good* logo. I do hope someone steps up to do
> better.
>
> Logos aside, I do feel the need to correct the record here: you
> clearly have not seen how quickly a turtle can move when offered banana
> or shrimp. They can be quite quick when suitably incentivized!
>
> 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/20200902/d5f7e971/attachment-0001.html>

From ben at smart-cactus.org  Wed Sep  2 16:09:30 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 02 Sep 2020 12:09:30 -0400
Subject: Creative ideas on how to debug heap corruption
In-Reply-To: <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
References: <CAKfdd-w9M6i9PHCnAxUfziEMBH__dyX-JZv8w0_jd9Q7HRr9Kg@mail.gmail.com>
 <89C6E06D-E58F-4F05-AD9E-0022502F9185@ouroborus.net>
Message-ID: <875z8wrwhx.fsf@smart-cactus.org>

Ben Lippmeier <benl at ouroborus.net> writes:

>> On 31 Aug 2020, at 5:54 pm, Moritz Angermann <moritz.angermann at gmail.com> wrote:
>> 
>> If anyone has some create ideas, I'd love to hear them.  I've been wondering
>> if just logging allocations (offset, range, type) would help figuring out what we
>> expected to be there; and then maybe try to break on the allocation, (and
>> subsequent writes).
>> 
>> I'm sure some have been down this road before. 
>
> Force a GC before every allocation, and make the GC check the validity
> of the objects before it moves anything. I think this used to be
> possible by compiling the runtime system in debug mode.
>
> The usual pain of heap corruption is that once the heap is corrupted
> it may be several GC cycles before you get the actual crash, and in
> the meantime the objects have all been moved around. The GC walks over
> all the objects by nature, so get it to validate the heap every time
> it does, then force it to run as often as you possibly can.
>
Indeed.  Small nurseries (using +RTS -A), deterministic GC behavior
(with +RTS -V0 -I0), and sanity checking (with +RTS -DS) are all a very
useful for this.

> A user space approach is to use a library like vacuum or packman that
> also walks over the heap objects directly.
>
> http://hackage.haskell.org/package/vacuum-2.2.0.0/docs/GHC-Vacuum.html
> https://hackage.haskell.org/package/packman
>
For what it's worth, the ghc-debug [1] project which Sven Tennie, Matt
Pickering, and I have been working on over the last year or so was in
part motivated by precisely this use-case. It would allow the heap of
one Haskell process's heap to be traversed by another process. This is
useful for both debugging and profiling use-cases.

Cheers,

- Ben


[1] https://github.com/bgamari/ghc-debug
-------------- 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/20200902/d4b75d26/attachment.sig>

From mail at joachim-breitner.de  Wed Sep  2 16:11:34 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 02 Sep 2020 18:11:34 +0200
Subject: GHC Logo
In-Reply-To: <15799004-4f66-9324-c250-36025e82c2e6@Obsidian.Systems>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
 <87bliorxi9.fsf@smart-cactus.org>
 <15799004-4f66-9324-c250-36025e82c2e6@Obsidian.Systems>
Message-ID: <b0d0051bfd856820799c07a0294b125ceaa53ab8.camel@joachim-breitner.de>

Quite a convincing plea :)


Am Mittwoch, den 02.09.2020, 12:07 -0400 schrieb John Cotton Ericson:
> Yeah I think the old "functional programming is slow" memes died off about when the rest of the industry went on its JavaScript bender, so I am not really worried about the negative connotations of turtles.
> The positive connotations of turtles sounds very good to me. Besides safety,
>  the longevity of at least giant tortoises also speaks to GHC's rare ability to stay at the vanguard of research while still being wildly used.
> Their ability to walk and swim speaks to the diverse backends that can be attached to GHC (NCG, LLVM, GHCJS, Asterius, Clash's, etc.).
> Even the fable, from which the slowness myth comes from I guess, goes well with "avoid success at all costs".
> Conversely I am not a fan of choosing a Cat. I like Cats fine in real life, don't get be wrong, but Cats are so popular on the internet that this would be the the unmarked animal choice, with no clear connotations or memorability. I think that would be the juvenile choice, per Ben's slippery slope.
> Foxes are nice, but I think Firefox has that for life.
> Octopuses are alright. GitHub's Octocat doesn't doesn't pose nearly as much of a problem as Firefox for foxes. Still, while Octopuses are smart, they are usually solitary and mischievous. GHC is very much a long-term group effort, belying the solitary connotation, and I certainly hope any compiler I use isn't mischievous!
> A turtle for a compiler is a bold choice that indicates our values, confidence that the performance of compiled code is immune to cheap derision, and humor.
> John
> P.S. The funny patterns on turtles' backs could be made of lambdas?...
> P.P.S. and yes, if it does compel us to fix rampant list appending just so we're fast on all fronts, that would be nice too :).
> On 9/2/20 11:47 AM, Ben Gamari wrote:
> > Richard Eisenberg <rae at richarde.dev> writes:
> > 
> > > I'm oddly drawn to the idea of a turtle -- except that turtles are
> > > slow. But animals are cute. Maybe something involving a fox, given
> > > that foxes can be clever? Octopuses are also known to be very clever,
> > > but maybe GitHub has octopuses covered.
> > > 
> > 
> > In general I'm rather neutral on the logo question. There is a fine line
> > between "juvenile" (which may detract from the project's credibility in
> > the eyes of some) and "cute" (which I think is universally a Good
> > Thing); the current rather boring logo was a quick attempt to satisfy
> > the need for some logo while recognizing that I lack the artistic
> > ability to walk that line. I don't think it's a bad logo but it's quite
> > dull and far from being a *good* logo. I do hope someone steps up to do
> > better.
> > 
> > Logos aside, I do feel the need to correct the record here: you
> > clearly have not seen how quickly a turtle can move when offered banana
> > or shrimp. They can be quite quick when suitably incentivized!
> > 
> > Cheers,
> > 
> > - Ben
> > 
> > 
> > _______________________________________________
> > 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
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From spam at scientician.net  Wed Sep  2 16:23:48 2020
From: spam at scientician.net (Bardur Arantsson)
Date: Wed, 2 Sep 2020 18:23:48 +0200
Subject: GHC Logo
In-Reply-To: <010f01744bd0e9be-f906f935-2ac1-4bd9-a730-a0c3724e765b-000000@us-east-2.amazonses.com>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <dd60d8fd-a349-6049-9cf1-71a6b36f9b10@nh2.me>
 <87mu2vapc9.fsf@smart-cactus.org>
 <CAHYVw0xpPsvkCGVtXT7NCJO-X0dBZ4fCicqWhmAfwLSz_TJO5w@mail.gmail.com>
 <87ft8madu1.fsf@smart-cactus.org>
 <CDFAC7D2-07FE-4BB4-AFDA-1E637ECACB9F@inconsistent.nl>
 <87bljaa1f1.fsf@smart-cactus.org>
 <010f01744bd0e9be-f906f935-2ac1-4bd9-a730-a0c3724e765b-000000@us-east-2.amazonses.com>
Message-ID: <rioguk$ami$1@ciao.gmane.io>

On 02/09/2020 00.36, Richard Eisenberg wrote:
> Late to the party here, but I'm wondering whether we can enlist someone with graphic design experience to create a more iconic logo for the compiler. I use the word "iconic" deliberately: it should both be recognizable, and in the shape of an icon (that is, more square). The Haskell logo does this wonderfully, but I think Ben's proposal just appends GHC to that.
> 
> My own preference would be to retain a connection with the Haskell logo (as Ben's submission does), but that needn't be a hard requirement.
> 

(Apologies, Richard, for the double-send. Screwed up the to-all thing.)

Is there no animal which could reasonably be "overlaid" on the logo? I'm
thinking the `` bit would be horns or ears and the // would be legs...
Not sure what the = would be... maybe front legs/arms?

Afraid I cannot draw anything, but I did a *horrific* "rest of the owl"
type thing here:

   https://sketch.io/render/sk-a412a3154e2332ae6d1c58fb23f00c04.jpeg

Regards,




From carter.schonwald at gmail.com  Wed Sep  2 18:16:30 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 2 Sep 2020 14:16:30 -0400
Subject: GHC Logo
In-Reply-To: <15799004-4f66-9324-c250-36025e82c2e6@Obsidian.Systems>
References: <87zh6w9fxf.fsf@smart-cactus.org>
 <CACNT4y4U2JA-E3ve8egPpMLEOiG5x+5taAwk_B-SiLGv6SLWQg@mail.gmail.com>
 <CAHYVw0xTj8mJAweHG5KVMY-bt-3JsSK4C8qvRZcKjZG0Yk_rcg@mail.gmail.com>
 <010f01744f2cd7f2-425b7e2a-40ab-43c8-acc7-7200281221be-000000@us-east-2.amazonses.com>
 <87bliorxi9.fsf@smart-cactus.org>
 <15799004-4f66-9324-c250-36025e82c2e6@Obsidian.Systems>
Message-ID: <CAHYVw0y_Y-wG0bU3LuvJNRJ1x6BnGJMYA9dwH+DwdsYK3b5r4Q@mail.gmail.com>

I decided to look up the difference between tortoise and turtles, and
apparently the former are land critters. Plus have elephant style hind feet
to support their high load/ weight among the larger species due to being
land focused.
https://www.nationalgeographic.com/news/2017/12/shell-game--how-to-tell-a-turtle-from-a-tortoise/


So there’s a cute stable under load angle there ;) at least for a tortoise
/ land turtle angle

On Wed, Sep 2, 2020 at 12:08 PM John Cotton Ericson
<John.Ericson at obsidian.systems> wrote:

>
>
>
>
>
>
>
>
>
>
> Yeah I think the old "functional programming is slow" memes died
>
> off about when the rest of the industry went on its JavaScript
>
> bender, so I am not really worried about the negative connotations
>
> of turtles.
>
>
> The positive connotations of turtles sounds very good to me.
>
> Besides safety,
>
>
>
>
>
>    -  the longevity of at least giant tortoises also speaks to
>
>    GHC's rare ability to stay at the vanguard of research while
>
>    still being wildly used.
>
>    - Their ability to walk and swim speaks to the diverse backends
>
>    that can be attached to GHC (NCG, LLVM, GHCJS, Asterius,
>
>    Clash's, etc.).
>
>    - Even the fable, from which the slowness myth comes from I
>
>    guess, goes well with "avoid success at all costs".
>
>
>
>
> Conversely I am not a fan of choosing a Cat. I like Cats fine in
>
> real life, don't get be wrong, but Cats are so popular on the
>
> internet that this would be the the unmarked animal choice, with
>
> no clear connotations or memorability. I think that would be the
>
> juvenile choice, per Ben's slippery slope.
>
>
>
>
> Foxes are nice, but I think Firefox has that for life.
>
>
> Octopuses are alright. GitHub's Octocat doesn't doesn't pose
>
> nearly as much of a problem as Firefox for foxes. Still, while
>
> Octopuses are smart, they are usually solitary and mischievous.
>
> GHC is very much a long-term group effort, belying the solitary
>
> connotation, and I certainly hope any compiler I use isn't
>
> mischievous!
>
>
>
>
> A turtle for a compiler is a bold choice that indicates our
>
> values, confidence that the performance of compiled code is immune
>
> to cheap derision, and humor.
>
>
> John
>
>
> P.S. The funny patterns on turtles' backs could be made of
>
> lambdas?...
>
>
> P.P.S. and yes, if it does compel us to fix rampant list
>
> appending just so we're fast on all fronts, that would be nice too
>
> :).
>
>
> On 9/2/20 11:47 AM, Ben Gamari wrote:
>
>
>
>
>
>
> Richard Eisenberg <rae at richarde.dev> <rae at richarde.dev> writes:
>
>
>
>
>
>
>
> I'm oddly drawn to the idea of a turtle -- except that turtles are
>
> slow. But animals are cute. Maybe something involving a fox, given
>
> that foxes can be clever? Octopuses are also known to be very clever,
>
> but maybe GitHub has octopuses covered.
>
>
>
>
>
>
>
> In general I'm rather neutral on the logo question. There is a fine line
>
> between "juvenile" (which may detract from the project's credibility in
>
> the eyes of some) and "cute" (which I think is universally a Good
>
> Thing); the current rather boring logo was a quick attempt to satisfy
>
> the need for some logo while recognizing that I lack the artistic
>
> ability to walk that line. I don't think it's a bad logo but it's quite
>
> dull and far from being a *good* logo. I do hope someone steps up to do
>
> better.
>
>
>
> Logos aside, I do feel the need to correct the record here: you
>
> clearly have not seen how quickly a turtle can move when offered banana
>
> or shrimp. They can be quite quick when suitably incentivized!
>
>
>
> Cheers,
>
>
>
> - Ben
>
>
>
>
>
>
>
>
> _______________________________________________
>
> 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/20200902/8b08f7d5/attachment.html>

From arnaud.spiwack at tweag.io  Thu Sep  3 12:47:15 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 3 Sep 2020 14:47:15 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>

>
> This thread is suggesting to add a special case -- one that seems to match
> intuition, but it's still a special case. And my question is: should the
> special case be for unboxed tuples? or should the special case be for any
> pattern whose overall type is unlifted?
>

My intuition would be: for all unlifted types. I'd submit that the
distinction between lazy and strict pattern-matching doesn't really make a
ton of sense for unlifted types. To implement lazy pattern-matching on an
unlifted type, one has to actually indirect through another type, which I
find deeply suspicious.

That being said

Right now, there is one rule: if the type of any variable bound in the
> pattern is unlifted, then the pattern is an unlifter-var pattern and is
> strict. The pattern must be banged, unless the bound variable is not
> nested. This rule is consistent across all features.
>

 I realise that there are a lot of subtil details to get right to specify
pattern-matching. Or at the very least, that it's difficult to come up with
a straightforward specification which is as clear as the one above.

I'm wondering though: have there been discussions which led to the above
rule, or did it just come to be, mostly informally? (and if there have been
explicit discussions, are they recorded somewhere?)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200903/0acc2dc4/attachment.html>

From sgraf1337 at gmail.com  Thu Sep  3 16:00:54 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 3 Sep 2020 18:00:54 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
Message-ID: <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>

Hi,

Right now, there is one rule: if the type of any variable bound in the
> pattern is unlifted, then the pattern is an unlifter-var pattern and is
> strict.
>

I think the intuition I followed so far was "bindings with unlifted *RHS*
are strict".
So if I take a program in a strict language with Haskell syntax (Idris with
a different syntax, not like -XStrict) and replace all types with their
unlifted counterparts (which should be possible once we have
-XUnliftedDatatypes), then I get exactly the same semantics in GHC Haskell.
I find this property very useful.
As a special case that means that any binders of unlifted type are bound
strictly, if only for uniformity with simple variable bindings. I think my
intuition is different to Richard's rule only for the "unlifted constructor
match with nested lifted-only variable matches" case.

Sebastian

Am Do., 3. Sept. 2020 um 14:48 Uhr schrieb Spiwack, Arnaud <
arnaud.spiwack at tweag.io>:

> This thread is suggesting to add a special case -- one that seems to match
>> intuition, but it's still a special case. And my question is: should the
>> special case be for unboxed tuples? or should the special case be for any
>> pattern whose overall type is unlifted?
>>
>
> My intuition would be: for all unlifted types. I'd submit that the
> distinction between lazy and strict pattern-matching doesn't really make a
> ton of sense for unlifted types. To implement lazy pattern-matching on an
> unlifted type, one has to actually indirect through another type, which I
> find deeply suspicious.
>
> That being said
>
> Right now, there is one rule: if the type of any variable bound in the
>> pattern is unlifted, then the pattern is an unlifter-var pattern and is
>> strict. The pattern must be banged, unless the bound variable is not
>> nested. This rule is consistent across all features.
>>
>
>  I realise that there are a lot of subtil details to get right to specify
> pattern-matching. Or at the very least, that it's difficult to come up with
> a straightforward specification which is as clear as the one above.
>
> I'm wondering though: have there been discussions which led to the above
> rule, or did it just come to be, mostly informally? (and if there have been
> explicit discussions, are they recorded somewhere?)
> _______________________________________________
> 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/20200903/577b048f/attachment.html>

From arnaud.spiwack at tweag.io  Thu Sep  3 16:10:49 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 3 Sep 2020 18:10:49 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
Message-ID: <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>

>
> Right now, there is one rule: if the type of any variable bound in the
>> pattern is unlifted, then the pattern is an unlifter-var pattern and is
>> strict.
>>
>
> I think the intuition I followed so far was "bindings with unlifted *RHS*
> are strict".
>

 This is a very different rule indeed! And one which gives a strict
semantic to the initial offender.

But there are holes in it: if I `let (x, y) = blah in …` and `x` is at an
unlifted type, the pattern _needs_ to be strict (this is solved by the
current rule as described by Richard) despite the rhs being at a lifted
type. That's because binding `x` forces the pattern anyway, by definition.
There are questions about nested patterns, as well. What about `let (U x,
y) = blah in …`, where `U` is some unlifted type. Is the nested `U x`
pattern strict? or is it lazy? There is no corresponding right-hand side.

This is all a tad tricky, I must say.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200903/50406fc4/attachment.html>

From sgraf1337 at gmail.com  Thu Sep  3 16:22:11 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 3 Sep 2020 18:22:11 +0200
Subject: COMPLETE pragmas
In-Reply-To: <788e388ef5e231e22a945c84748043c28ba8d493.camel@joachim-breitner.de>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
 <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
 <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>
 <CAJumaK8ARUvkU5R7sWHQgAoPHPreE29DwNoxrLs7xi9nU1hzpw@mail.gmail.com>
 <CAAS+=P__xdryerMhBL3saBpoihRG6skBP5DE+hXkOcC6HSbv9Q@mail.gmail.com>
 <788e388ef5e231e22a945c84748043c28ba8d493.camel@joachim-breitner.de>
Message-ID: <CAAS+=P9vOb7KcA7H1Tkw6xd74RQbL9a5kNxaPp0OmCzXGys03g@mail.gmail.com>

Hi folks,

I implemented what I had in mind in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3959. CI should turn
green any hour now, so feel free to play with it if you want to.
With the wonderful https://github.com/mpickering/ghc-artefact-nix it will
just be `ghc-head-from 3959`.

Cheers,
Sebastian

Am Di., 1. Sept. 2020 um 22:09 Uhr schrieb Joachim Breitner <
mail at joachim-breitner.de>:

> Am Dienstag, den 01.09.2020, 10:11 +0200 schrieb Sebastian Graf:
> > > 2.) Another scenario that I'd really love to see supported with
> > > COMPLETE pragmas is a way to use | notation with them like you can
> > > with MINIMAL pragmas.
> >
> > (2) is a neat idea, but requires a GHC proposal I'm not currently
> > willing to get into. I can also see a design discussion around
> > allowing arbitrary "formulas" (e.g., not only what is effectively
> > CNF).
> >
> > A big bonus of your design is that it's really easy to integrate into
> > the current implementation, which is what I'd gladly do in case such
> > a proposal would get accepted.
>
> in the original ticket where a COMPLETE pragma was suggested (
> https://gitlab.haskell.org/ghc/ghc/-/issues/8779) the ability to
> specify arbitrary boolean formulas was already present:
>
> “So here is what I think might work well, inspired by the new MINIMAL
> pragma: … The syntax is essentially the same as for MINIMAL, i.e. a
> boolean formula, with constructors and pattern synonyms as atoms. In
> this case”
>
> So one _could_ say that this doesn’t need a proposal, because it would
> just be the implementation finishing the original task ;-)
>
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> 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/20200903/72f3ea81/attachment.html>

From rae at richarde.dev  Thu Sep  3 17:37:59 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Sep 2020 17:37:59 +0000
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
Message-ID: <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>



> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> This is all a tad tricky, I must say.

... which is one of the reasons I originally wanted one simple rule. I'm not now saying I was in the right, but it is an attractive resting point for this discussion.

To be clear, I don't think there's going to be any concrete action here without a proposal, so perhaps once this thread finds a resting point different than the status quo, someone will have to write it up.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200903/75c73f6d/attachment.html>

From iavor.diatchki at gmail.com  Thu Sep  3 17:51:31 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Sep 2020 10:51:31 -0700
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>

How about the following rule:  unlifted patterns are always strict (i.e.,
you desugar them as if they had an explicit  `!`).   A pattern is
"unlifted" if the type it examines is unlifted.   Seems simple enough and,
I think, it would do what most folks would expect.

I guess a more explicit option would be to make it an error to use a lazy
pattern on an unlifted type, and require programmers to manually add the
`!` but I am not sure that gains much, and is more work in the compiler.

-Iavor

On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> This is all a tad tricky, I must say.
>
>
> ... which is one of the reasons I originally wanted one simple rule. I'm
> not now saying I was in the right, but it is an attractive resting point
> for this discussion.
>
> To be clear, I don't think there's going to be any concrete action here
> without a proposal, so perhaps once this thread finds a resting point
> different than the status quo, someone will have to write it up.
>
> 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/20200903/5a4094cf/attachment.html>

From rae at richarde.dev  Thu Sep  3 18:02:09 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 3 Sep 2020 18:02:09 +0000
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
 <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
Message-ID: <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>



> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> How about the following rule:  unlifted patterns are always strict (i.e., you desugar them as if they had an explicit  `!`).   A pattern is "unlifted" if the type it examines is unlifted.   Seems simple enough and, I think, it would do what most folks would expect.  

I don't think it's this simple. For example:

> data X = MkX Int#
>
> a = let MkX 3# = undefined in ()
> b = let MkX z = undefined in ()
> c = let MkX _ = undefined in ()
> d = let MkX {} = undefined in ()
> e = let _ :: X = undefined in ()

Which of these diverge? e definitely converges, as X is lifted. b definitely diverges, because it binds z, a variable of an unlifted type, to a component of a diverging computation.

In GHC today, all the cases other than b converge.

Iavor suggests that a should diverge: 3# is a pattern of an unlifted type. What about c? What about d? Very unclear to me.

Note that banging the pattern nested inside the MkX does not change the behavior (in GHC today) for any of the cases where this makes sense to do so.

Richard

> 
> I guess a more explicit option would be to make it an error to use a lazy pattern on an unlifted type, and require programmers to manually add the `!` but I am not sure that gains much, and is more work in the compiler.
> 
> -Iavor
> 
> On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> 
> 
>> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
>> 
>> This is all a tad tricky, I must say.
> 
> ... which is one of the reasons I originally wanted one simple rule. I'm not now saying I was in the right, but it is an attractive resting point for this discussion.
> 
> To be clear, I don't think there's going to be any concrete action here without a proposal, so perhaps once this thread finds a resting point different than the status quo, someone will have to write it up.
> 
> 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/20200903/8a926a01/attachment.html>

From iavor.diatchki at gmail.com  Thu Sep  3 18:41:59 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 3 Sep 2020 11:41:59 -0700
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
 <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
 <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nupUganbwfj51yV=O0AKEKCgpjkygj9t_AXyaV=Kv8KDdQ@mail.gmail.com>

Yeah, I think these are nice examples that illustrate some of the
problems with the current behavior of GHC.   For example, I think it is
weird that `b` non-terminates, but `c` does, because `z` is not used.  I
would expect those to be equivalent.

My preference would be to use the simple rule I mentioned before, but
change how bang patterns work in pattern bindings.  In particular, I think
writing a bang pattern should constitute a use of the banged value.  I
think two equivalent ways to specify this is to say that a) writing a
nested bang pattern implicitly adds bangs to the enclosing patterns, or I
think equivalently b) writing `!p` is the same as writing `x at p` and adding
`seq x` the same way we do for simple `!x = e` definitions

With this interpretation, all but `e` would diverge, which matches my
intuition of how unboxed types should work.

-Iavor


On Thu, Sep 3, 2020 at 11:02 AM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> How about the following rule:  unlifted patterns are always strict (i.e.,
> you desugar them as if they had an explicit  `!`).   A pattern is
> "unlifted" if the type it examines is unlifted.   Seems simple enough and,
> I think, it would do what most folks would expect.
>
>
> I don't think it's this simple. For example:
>
> > data X = MkX Int#
> >
> > a = let MkX 3# = undefined in ()
> > b = let MkX z = undefined in ()
> > c = let MkX _ = undefined in ()
> > d = let MkX {} = undefined in ()
> > e = let _ :: X = undefined in ()
>
> Which of these diverge? e definitely converges, as X is lifted. b
> definitely diverges, because it binds z, a variable of an unlifted type, to
> a component of a diverging computation.
>
> In GHC today, all the cases other than b converge.
>
> Iavor suggests that a should diverge: 3# is a pattern of an unlifted type.
> What about c? What about d? Very unclear to me.
>
> Note that banging the pattern nested inside the MkX does not change the
> behavior (in GHC today) for any of the cases where this makes sense to do
> so.
>
> Richard
>
>
> I guess a more explicit option would be to make it an error to use a lazy
> pattern on an unlifted type, and require programmers to manually add the
> `!` but I am not sure that gains much, and is more work in the compiler.
>
> -Iavor
>
> On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>>
>>
>> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> This is all a tad tricky, I must say.
>>
>>
>> ... which is one of the reasons I originally wanted one simple rule. I'm
>> not now saying I was in the right, but it is an attractive resting point
>> for this discussion.
>>
>> To be clear, I don't think there's going to be any concrete action here
>> without a proposal, so perhaps once this thread finds a resting point
>> different than the status quo, someone will have to write it up.
>>
>> 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/20200903/d68295b3/attachment.html>

From carter.schonwald at gmail.com  Thu Sep  3 18:46:55 2020
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 3 Sep 2020 14:46:55 -0400
Subject: COMPLETE pragmas
In-Reply-To: <CAAS+=P9vOb7KcA7H1Tkw6xd74RQbL9a5kNxaPp0OmCzXGys03g@mail.gmail.com>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
 <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
 <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>
 <CAJumaK8ARUvkU5R7sWHQgAoPHPreE29DwNoxrLs7xi9nU1hzpw@mail.gmail.com>
 <CAAS+=P__xdryerMhBL3saBpoihRG6skBP5DE+hXkOcC6HSbv9Q@mail.gmail.com>
 <788e388ef5e231e22a945c84748043c28ba8d493.camel@joachim-breitner.de>
 <CAAS+=P9vOb7KcA7H1Tkw6xd74RQbL9a5kNxaPp0OmCzXGys03g@mail.gmail.com>
Message-ID: <CAHYVw0wMZpkpMh+sjzPvqvQJjdg6gpLTsf5Lg4xPudxWVbhHOw@mail.gmail.com>

wonderful!

On Thu, Sep 3, 2020 at 12:22 PM Sebastian Graf <sgraf1337 at gmail.com> wrote:

> Hi folks,
>
> I implemented what I had in mind in
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3959. CI should turn
> green any hour now, so feel free to play with it if you want to.
> With the wonderful https://github.com/mpickering/ghc-artefact-nix it will
> just be `ghc-head-from 3959`.
>
> Cheers,
> Sebastian
>
> Am Di., 1. Sept. 2020 um 22:09 Uhr schrieb Joachim Breitner <
> mail at joachim-breitner.de>:
>
>> Am Dienstag, den 01.09.2020, 10:11 +0200 schrieb Sebastian Graf:
>> > > 2.) Another scenario that I'd really love to see supported with
>> > > COMPLETE pragmas is a way to use | notation with them like you can
>> > > with MINIMAL pragmas.
>> >
>> > (2) is a neat idea, but requires a GHC proposal I'm not currently
>> > willing to get into. I can also see a design discussion around
>> > allowing arbitrary "formulas" (e.g., not only what is effectively
>> > CNF).
>> >
>> > A big bonus of your design is that it's really easy to integrate into
>> > the current implementation, which is what I'd gladly do in case such
>> > a proposal would get accepted.
>>
>> in the original ticket where a COMPLETE pragma was suggested (
>> https://gitlab.haskell.org/ghc/ghc/-/issues/8779) the ability to
>> specify arbitrary boolean formulas was already present:
>>
>> “So here is what I think might work well, inspired by the new MINIMAL
>> pragma: … The syntax is essentially the same as for MINIMAL, i.e. a
>> boolean formula, with constructors and pattern synonyms as atoms. In
>> this case”
>>
>> So one _could_ say that this doesn’t need a proposal, because it would
>> just be the implementation finishing the original task ;-)
>>
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> 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/20200903/08819d1b/attachment.html>

From facundo.dominguez at tweag.io  Thu Sep  3 18:58:55 2020
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Dom=C3=ADnguez=2C_Facundo?=)
Date: Thu, 3 Sep 2020 15:58:55 -0300
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAGK9nupUganbwfj51yV=O0AKEKCgpjkygj9t_AXyaV=Kv8KDdQ@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
 <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
 <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>
 <CAGK9nupUganbwfj51yV=O0AKEKCgpjkygj9t_AXyaV=Kv8KDdQ@mail.gmail.com>
Message-ID: <CAF7SUTSydB+Pc_n1CkOsWAHEZ3RFK8q2xAZZqQiH10ue6AJVKA@mail.gmail.com>

> I guess a more explicit option would be to make it an error to use a lazy
pattern on an unlifted type, and require programmers to manually add the
`!` but I am not sure that gains much, and is more work in the compiler.

Not being used to deal with unlifted types, this would be my preferred
option. Having the meaning of let change depending on the levity of the
type is a good opportunity for confusion.

Cheers,
Facundo


On Thu, Sep 3, 2020 at 3:43 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Yeah, I think these are nice examples that illustrate some of the
> problems with the current behavior of GHC.   For example, I think it is
> weird that `b` non-terminates, but `c` does, because `z` is not used.  I
> would expect those to be equivalent.
>
> My preference would be to use the simple rule I mentioned before, but
> change how bang patterns work in pattern bindings.  In particular, I think
> writing a bang pattern should constitute a use of the banged value.  I
> think two equivalent ways to specify this is to say that a) writing a
> nested bang pattern implicitly adds bangs to the enclosing patterns, or I
> think equivalently b) writing `!p` is the same as writing `x at p` and
> adding `seq x` the same way we do for simple `!x = e` definitions
>
> With this interpretation, all but `e` would diverge, which matches my
> intuition of how unboxed types should work.
>
> -Iavor
>
>
> On Thu, Sep 3, 2020 at 11:02 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>>
>>
>> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>> How about the following rule:  unlifted patterns are always strict (i.e.,
>> you desugar them as if they had an explicit  `!`).   A pattern is
>> "unlifted" if the type it examines is unlifted.   Seems simple enough and,
>> I think, it would do what most folks would expect.
>>
>>
>> I don't think it's this simple. For example:
>>
>> > data X = MkX Int#
>> >
>> > a = let MkX 3# = undefined in ()
>> > b = let MkX z = undefined in ()
>> > c = let MkX _ = undefined in ()
>> > d = let MkX {} = undefined in ()
>> > e = let _ :: X = undefined in ()
>>
>> Which of these diverge? e definitely converges, as X is lifted. b
>> definitely diverges, because it binds z, a variable of an unlifted type, to
>> a component of a diverging computation.
>>
>> In GHC today, all the cases other than b converge.
>>
>> Iavor suggests that a should diverge: 3# is a pattern of an unlifted
>> type. What about c? What about d? Very unclear to me.
>>
>> Note that banging the pattern nested inside the MkX does not change the
>> behavior (in GHC today) for any of the cases where this makes sense to do
>> so.
>>
>> Richard
>>
>>
>> I guess a more explicit option would be to make it an error to use a lazy
>> pattern on an unlifted type, and require programmers to manually add the
>> `!` but I am not sure that gains much, and is more work in the compiler.
>>
>> -Iavor
>>
>> On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
>> wrote:
>>
>>>
>>>
>>> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>> This is all a tad tricky, I must say.
>>>
>>>
>>> ... which is one of the reasons I originally wanted one simple rule. I'm
>>> not now saying I was in the right, but it is an attractive resting point
>>> for this discussion.
>>>
>>> To be clear, I don't think there's going to be any concrete action here
>>> without a proposal, so perhaps once this thread finds a resting point
>>> different than the status quo, someone will have to write it up.
>>>
>>> Richard
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200903/dab1f76d/attachment.html>

From chessai1996 at gmail.com  Thu Sep  3 19:02:07 2020
From: chessai1996 at gmail.com (chessai)
Date: Thu, 3 Sep 2020 14:02:07 -0500
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAF7SUTSydB+Pc_n1CkOsWAHEZ3RFK8q2xAZZqQiH10ue6AJVKA@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
 <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
 <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>
 <CAGK9nupUganbwfj51yV=O0AKEKCgpjkygj9t_AXyaV=Kv8KDdQ@mail.gmail.com>
 <CAF7SUTSydB+Pc_n1CkOsWAHEZ3RFK8q2xAZZqQiH10ue6AJVKA@mail.gmail.com>
Message-ID: <CAD34_kJ1auApk73hNmZMv8nBMP8yew+goGirfX2Lk-jMOrRfpg@mail.gmail.com>

Not saying it's the best option, but it is an idea: Perhaps the behaviour
could stay the same, but the proposed behaviour could sit behind a language
pragma? I myself would always enable that pragma.

On Thu, Sep 3, 2020, 13:59 Domínguez, Facundo <facundo.dominguez at tweag.io>
wrote:

> > I guess a more explicit option would be to make it an error to use a
> lazy pattern on an unlifted type, and require programmers to manually add
> the `!` but I am not sure that gains much, and is more work in the compiler.
>
> Not being used to deal with unlifted types, this would be my preferred
> option. Having the meaning of let change depending on the levity of the
> type is a good opportunity for confusion.
>
> Cheers,
> Facundo
>
>
> On Thu, Sep 3, 2020 at 3:43 PM Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> Yeah, I think these are nice examples that illustrate some of the
>> problems with the current behavior of GHC.   For example, I think it is
>> weird that `b` non-terminates, but `c` does, because `z` is not used.  I
>> would expect those to be equivalent.
>>
>> My preference would be to use the simple rule I mentioned before, but
>> change how bang patterns work in pattern bindings.  In particular, I think
>> writing a bang pattern should constitute a use of the banged value.  I
>> think two equivalent ways to specify this is to say that a) writing a
>> nested bang pattern implicitly adds bangs to the enclosing patterns, or I
>> think equivalently b) writing `!p` is the same as writing `x at p` and
>> adding `seq x` the same way we do for simple `!x = e` definitions
>>
>> With this interpretation, all but `e` would diverge, which matches my
>> intuition of how unboxed types should work.
>>
>> -Iavor
>>
>>
>> On Thu, Sep 3, 2020 at 11:02 AM Richard Eisenberg <rae at richarde.dev>
>> wrote:
>>
>>>
>>>
>>> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>>> wrote:
>>>
>>> How about the following rule:  unlifted patterns are always strict
>>> (i.e., you desugar them as if they had an explicit  `!`).   A pattern is
>>> "unlifted" if the type it examines is unlifted.   Seems simple enough and,
>>> I think, it would do what most folks would expect.
>>>
>>>
>>> I don't think it's this simple. For example:
>>>
>>> > data X = MkX Int#
>>> >
>>> > a = let MkX 3# = undefined in ()
>>> > b = let MkX z = undefined in ()
>>> > c = let MkX _ = undefined in ()
>>> > d = let MkX {} = undefined in ()
>>> > e = let _ :: X = undefined in ()
>>>
>>> Which of these diverge? e definitely converges, as X is lifted. b
>>> definitely diverges, because it binds z, a variable of an unlifted type, to
>>> a component of a diverging computation.
>>>
>>> In GHC today, all the cases other than b converge.
>>>
>>> Iavor suggests that a should diverge: 3# is a pattern of an unlifted
>>> type. What about c? What about d? Very unclear to me.
>>>
>>> Note that banging the pattern nested inside the MkX does not change the
>>> behavior (in GHC today) for any of the cases where this makes sense to do
>>> so.
>>>
>>> Richard
>>>
>>>
>>> I guess a more explicit option would be to make it an error to use a
>>> lazy pattern on an unlifted type, and require programmers to manually add
>>> the `!` but I am not sure that gains much, and is more work in the compiler.
>>>
>>> -Iavor
>>>
>>> On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>> This is all a tad tricky, I must say.
>>>>
>>>>
>>>> ... which is one of the reasons I originally wanted one simple rule.
>>>> I'm not now saying I was in the right, but it is an attractive resting
>>>> point for this discussion.
>>>>
>>>> To be clear, I don't think there's going to be any concrete action here
>>>> without a proposal, so perhaps once this thread finds a resting point
>>>> different than the status quo, someone will have to write it up.
>>>>
>>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200903/e11d241f/attachment-0001.html>

From ekmett at gmail.com  Thu Sep  3 20:31:20 2020
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 3 Sep 2020 13:31:20 -0700
Subject: COMPLETE pragmas
In-Reply-To: <CAAS+=P9vOb7KcA7H1Tkw6xd74RQbL9a5kNxaPp0OmCzXGys03g@mail.gmail.com>
References: <010f017445ff7d3e-e5395db8-776e-412e-9a66-d12c8ae3177d-000000@us-east-2.amazonses.com>
 <CAAS+=P8_aOr+=bYM-s_JasR6sPjuVTPXU7OicS3sBNEA81cy7w@mail.gmail.com>
 <010f0174466c8088-93ed323f-9cdf-401a-9348-58e1c0adc1a6-000000@us-east-2.amazonses.com>
 <CAJumaK8ARUvkU5R7sWHQgAoPHPreE29DwNoxrLs7xi9nU1hzpw@mail.gmail.com>
 <CAAS+=P__xdryerMhBL3saBpoihRG6skBP5DE+hXkOcC6HSbv9Q@mail.gmail.com>
 <788e388ef5e231e22a945c84748043c28ba8d493.camel@joachim-breitner.de>
 <CAAS+=P9vOb7KcA7H1Tkw6xd74RQbL9a5kNxaPp0OmCzXGys03g@mail.gmail.com>
Message-ID: <CAJumaK947o0m_QQHO+-dV8TYeJAMtUDtdjrQ_-sNmvNFQ4A8ZQ@mail.gmail.com>

You are my hero.

On Thu, Sep 3, 2020 at 9:22 AM Sebastian Graf <sgraf1337 at gmail.com> wrote:

> Hi folks,
>
> I implemented what I had in mind in
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3959. CI should turn
> green any hour now, so feel free to play with it if you want to.
> With the wonderful https://github.com/mpickering/ghc-artefact-nix it will
> just be `ghc-head-from 3959`.
>
> Cheers,
> Sebastian
>
> Am Di., 1. Sept. 2020 um 22:09 Uhr schrieb Joachim Breitner <
> mail at joachim-breitner.de>:
>
>> Am Dienstag, den 01.09.2020, 10:11 +0200 schrieb Sebastian Graf:
>> > > 2.) Another scenario that I'd really love to see supported with
>> > > COMPLETE pragmas is a way to use | notation with them like you can
>> > > with MINIMAL pragmas.
>> >
>> > (2) is a neat idea, but requires a GHC proposal I'm not currently
>> > willing to get into. I can also see a design discussion around
>> > allowing arbitrary "formulas" (e.g., not only what is effectively
>> > CNF).
>> >
>> > A big bonus of your design is that it's really easy to integrate into
>> > the current implementation, which is what I'd gladly do in case such
>> > a proposal would get accepted.
>>
>> in the original ticket where a COMPLETE pragma was suggested (
>> https://gitlab.haskell.org/ghc/ghc/-/issues/8779) the ability to
>> specify arbitrary boolean formulas was already present:
>>
>> “So here is what I think might work well, inspired by the new MINIMAL
>> pragma: … The syntax is essentially the same as for MINIMAL, i.e. a
>> boolean formula, with constructors and pattern synonyms as atoms. In
>> this case”
>>
>> So one _could_ say that this doesn’t need a proposal, because it would
>> just be the implementation finishing the original task ;-)
>>
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> 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/20200903/90e07fb6/attachment.html>

From arnaud.spiwack at tweag.io  Fri Sep  4 09:28:20 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 4 Sep 2020 11:28:20 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAD34_kJ1auApk73hNmZMv8nBMP8yew+goGirfX2Lk-jMOrRfpg@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
 <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
 <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>
 <CAGK9nupUganbwfj51yV=O0AKEKCgpjkygj9t_AXyaV=Kv8KDdQ@mail.gmail.com>
 <CAF7SUTSydB+Pc_n1CkOsWAHEZ3RFK8q2xAZZqQiH10ue6AJVKA@mail.gmail.com>
 <CAD34_kJ1auApk73hNmZMv8nBMP8yew+goGirfX2Lk-jMOrRfpg@mail.gmail.com>
Message-ID: <CAH6fHQnNyjJqbeSsUkewJXHrye_5VFa0kbfaFEXLbY03wK1aMQ@mail.gmail.com>

Iavor:

Yeah, I think these are nice examples that illustrate some of the problems
with the current behavior of GHC. For example, I think it is weird that b
non-terminates, but c does, because z is not used. I would expect those to
be equivalent.

What about if I rewrite all these patterns as

data X = MkX Int#
a = let ~(MkX 3#) = undefined in ()b = let ~(MkX z) = undefined in ()c
= let ~(MkX _) = undefined in ()d = let ~(MkX {}) = undefined in ()e =
let ~(_ :: X) = undefined in ()

Do you still expect c to diverge?

On Thu, Sep 3, 2020 at 9:04 PM chessai <chessai1996 at gmail.com> wrote:

> Not saying it's the best option, but it is an idea: Perhaps the behaviour
> could stay the same, but the proposed behaviour could sit behind a language
> pragma? I myself would always enable that pragma.
>
> On Thu, Sep 3, 2020, 13:59 Domínguez, Facundo <facundo.dominguez at tweag.io>
> wrote:
>
>> > I guess a more explicit option would be to make it an error to use a
>> lazy pattern on an unlifted type, and require programmers to manually add
>> the `!` but I am not sure that gains much, and is more work in the compiler.
>>
>> Not being used to deal with unlifted types, this would be my preferred
>> option. Having the meaning of let change depending on the levity of the
>> type is a good opportunity for confusion.
>>
>> Cheers,
>> Facundo
>>
>>
>> On Thu, Sep 3, 2020 at 3:43 PM Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>>> Yeah, I think these are nice examples that illustrate some of the
>>> problems with the current behavior of GHC.   For example, I think it is
>>> weird that `b` non-terminates, but `c` does, because `z` is not used.  I
>>> would expect those to be equivalent.
>>>
>>> My preference would be to use the simple rule I mentioned before, but
>>> change how bang patterns work in pattern bindings.  In particular, I think
>>> writing a bang pattern should constitute a use of the banged value.  I
>>> think two equivalent ways to specify this is to say that a) writing a
>>> nested bang pattern implicitly adds bangs to the enclosing patterns, or I
>>> think equivalently b) writing `!p` is the same as writing `x at p` and
>>> adding `seq x` the same way we do for simple `!x = e` definitions
>>>
>>> With this interpretation, all but `e` would diverge, which matches my
>>> intuition of how unboxed types should work.
>>>
>>> -Iavor
>>>
>>>
>>> On Thu, Sep 3, 2020 at 11:02 AM Richard Eisenberg <rae at richarde.dev>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>>>> wrote:
>>>>
>>>> How about the following rule:  unlifted patterns are always strict
>>>> (i.e., you desugar them as if they had an explicit  `!`).   A pattern is
>>>> "unlifted" if the type it examines is unlifted.   Seems simple enough and,
>>>> I think, it would do what most folks would expect.
>>>>
>>>>
>>>> I don't think it's this simple. For example:
>>>>
>>>> > data X = MkX Int#
>>>> >
>>>> > a = let MkX 3# = undefined in ()
>>>> > b = let MkX z = undefined in ()
>>>> > c = let MkX _ = undefined in ()
>>>> > d = let MkX {} = undefined in ()
>>>> > e = let _ :: X = undefined in ()
>>>>
>>>> Which of these diverge? e definitely converges, as X is lifted. b
>>>> definitely diverges, because it binds z, a variable of an unlifted type, to
>>>> a component of a diverging computation.
>>>>
>>>> In GHC today, all the cases other than b converge.
>>>>
>>>> Iavor suggests that a should diverge: 3# is a pattern of an unlifted
>>>> type. What about c? What about d? Very unclear to me.
>>>>
>>>> Note that banging the pattern nested inside the MkX does not change the
>>>> behavior (in GHC today) for any of the cases where this makes sense to do
>>>> so.
>>>>
>>>> Richard
>>>>
>>>>
>>>> I guess a more explicit option would be to make it an error to use a
>>>> lazy pattern on an unlifted type, and require programmers to manually add
>>>> the `!` but I am not sure that gains much, and is more work in the compiler.
>>>>
>>>> -Iavor
>>>>
>>>> On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>>> wrote:
>>>>>
>>>>> This is all a tad tricky, I must say.
>>>>>
>>>>>
>>>>> ... which is one of the reasons I originally wanted one simple rule.
>>>>> I'm not now saying I was in the right, but it is an attractive resting
>>>>> point for this discussion.
>>>>>
>>>>> To be clear, I don't think there's going to be any concrete action
>>>>> here without a proposal, so perhaps once this thread finds a resting point
>>>>> different than the status quo, someone will have to write it up.
>>>>>
>>>>> 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
>>
> _______________________________________________
> 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/20200904/df7208ca/attachment.html>

From iavor.diatchki at gmail.com  Fri Sep  4 15:47:03 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Fri, 4 Sep 2020 08:47:03 -0700
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQnNyjJqbeSsUkewJXHrye_5VFa0kbfaFEXLbY03wK1aMQ@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
 <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
 <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>
 <CAGK9nupUganbwfj51yV=O0AKEKCgpjkygj9t_AXyaV=Kv8KDdQ@mail.gmail.com>
 <CAF7SUTSydB+Pc_n1CkOsWAHEZ3RFK8q2xAZZqQiH10ue6AJVKA@mail.gmail.com>
 <CAD34_kJ1auApk73hNmZMv8nBMP8yew+goGirfX2Lk-jMOrRfpg@mail.gmail.com>
 <CAH6fHQnNyjJqbeSsUkewJXHrye_5VFa0kbfaFEXLbY03wK1aMQ@mail.gmail.com>
Message-ID: <CAGK9nur-ASuiQHaH5c8e2+_-z6T_X-159e0W3LPGC4JYpZ9fNA@mail.gmail.com>

Yes

On Fri, Sep 4, 2020 at 2:29 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Iavor:
>
> Yeah, I think these are nice examples that illustrate some of the problems
> with the current behavior of GHC. For example, I think it is weird that b
> non-terminates, but c does, because z is not used. I would expect those
> to be equivalent.
>
> What about if I rewrite all these patterns as
>
> data X = MkX Int#
> a = let ~(MkX 3#) = undefined in ()b = let ~(MkX z) = undefined in ()c = let ~(MkX _) = undefined in ()d = let ~(MkX {}) = undefined in ()e = let ~(_ :: X) = undefined in ()
>
> Do you still expect c to diverge?
>
> On Thu, Sep 3, 2020 at 9:04 PM chessai <chessai1996 at gmail.com> wrote:
>
>> Not saying it's the best option, but it is an idea: Perhaps the behaviour
>> could stay the same, but the proposed behaviour could sit behind a language
>> pragma? I myself would always enable that pragma.
>>
>> On Thu, Sep 3, 2020, 13:59 Domínguez, Facundo <facundo.dominguez at tweag.io>
>> wrote:
>>
>>> > I guess a more explicit option would be to make it an error to use a
>>> lazy pattern on an unlifted type, and require programmers to manually add
>>> the `!` but I am not sure that gains much, and is more work in the compiler.
>>>
>>> Not being used to deal with unlifted types, this would be my preferred
>>> option. Having the meaning of let change depending on the levity of the
>>> type is a good opportunity for confusion.
>>>
>>> Cheers,
>>> Facundo
>>>
>>>
>>> On Thu, Sep 3, 2020 at 3:43 PM Iavor Diatchki <iavor.diatchki at gmail.com>
>>> wrote:
>>>
>>>> Yeah, I think these are nice examples that illustrate some of the
>>>> problems with the current behavior of GHC.   For example, I think it is
>>>> weird that `b` non-terminates, but `c` does, because `z` is not used.  I
>>>> would expect those to be equivalent.
>>>>
>>>> My preference would be to use the simple rule I mentioned before, but
>>>> change how bang patterns work in pattern bindings.  In particular, I think
>>>> writing a bang pattern should constitute a use of the banged value.  I
>>>> think two equivalent ways to specify this is to say that a) writing a
>>>> nested bang pattern implicitly adds bangs to the enclosing patterns, or I
>>>> think equivalently b) writing `!p` is the same as writing `x at p` and
>>>> adding `seq x` the same way we do for simple `!x = e` definitions
>>>>
>>>> With this interpretation, all but `e` would diverge, which matches my
>>>> intuition of how unboxed types should work.
>>>>
>>>> -Iavor
>>>>
>>>>
>>>> On Thu, Sep 3, 2020 at 11:02 AM Richard Eisenberg <rae at richarde.dev>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sep 3, 2020, at 1:51 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>>>>> wrote:
>>>>>
>>>>> How about the following rule:  unlifted patterns are always strict
>>>>> (i.e., you desugar them as if they had an explicit  `!`).   A pattern is
>>>>> "unlifted" if the type it examines is unlifted.   Seems simple enough and,
>>>>> I think, it would do what most folks would expect.
>>>>>
>>>>>
>>>>> I don't think it's this simple. For example:
>>>>>
>>>>> > data X = MkX Int#
>>>>> >
>>>>> > a = let MkX 3# = undefined in ()
>>>>> > b = let MkX z = undefined in ()
>>>>> > c = let MkX _ = undefined in ()
>>>>> > d = let MkX {} = undefined in ()
>>>>> > e = let _ :: X = undefined in ()
>>>>>
>>>>> Which of these diverge? e definitely converges, as X is lifted. b
>>>>> definitely diverges, because it binds z, a variable of an unlifted type, to
>>>>> a component of a diverging computation.
>>>>>
>>>>> In GHC today, all the cases other than b converge.
>>>>>
>>>>> Iavor suggests that a should diverge: 3# is a pattern of an unlifted
>>>>> type. What about c? What about d? Very unclear to me.
>>>>>
>>>>> Note that banging the pattern nested inside the MkX does not change
>>>>> the behavior (in GHC today) for any of the cases where this makes sense to
>>>>> do so.
>>>>>
>>>>> Richard
>>>>>
>>>>>
>>>>> I guess a more explicit option would be to make it an error to use a
>>>>> lazy pattern on an unlifted type, and require programmers to manually add
>>>>> the `!` but I am not sure that gains much, and is more work in the compiler.
>>>>>
>>>>> -Iavor
>>>>>
>>>>> On Thu, Sep 3, 2020 at 10:38 AM Richard Eisenberg <rae at richarde.dev>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 3, 2020, at 12:10 PM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>>>>>> wrote:
>>>>>>
>>>>>> This is all a tad tricky, I must say.
>>>>>>
>>>>>>
>>>>>> ... which is one of the reasons I originally wanted one simple rule.
>>>>>> I'm not now saying I was in the right, but it is an attractive resting
>>>>>> point for this discussion.
>>>>>>
>>>>>> To be clear, I don't think there's going to be any concrete action
>>>>>> here without a proposal, so perhaps once this thread finds a resting point
>>>>>> different than the status quo, someone will have to write it up.
>>>>>>
>>>>>> 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
>>>
>> _______________________________________________
>> 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/20200904/8a6a1e2a/attachment.html>

From arnaud.spiwack at tweag.io  Mon Sep  7 07:10:27 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 7 Sep 2020 09:10:27 +0200
Subject: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAGK9nur-ASuiQHaH5c8e2+_-z6T_X-159e0W3LPGC4JYpZ9fNA@mail.gmail.com>
References: <CAH6fHQmJJ0fRLsyyYD-TFCpttRZ15fMnZMGipSOpWUhUgyR9Eg@mail.gmail.com>
 <CAHYVw0ydZSsQmmif5Q8+KCH3tnOg78VJ6Nj1MWBuDd1N_0zJ-g@mail.gmail.com>
 <CAH6fHQ=ms1sr6o62Vg7vt_GDESzrwOHXLMYDG+v=h5hPe50jMg@mail.gmail.com>
 <CAD34_kLZyv_O_jwu4TuKToS6x+DWgJjMMvWmqJmdpM=OzAivZA@mail.gmail.com>
 <CAH6fHQ=Uj5d2JpV3hxZgAdowZ2xZKCjnGQ0j30K4iJD3MfqifQ@mail.gmail.com>
 <010f017445f119ac-4e5009bc-446d-4bc7-a6bc-3fd713318fd3-000000@us-east-2.amazonses.com>
 <CAH6fHQkXuzD-OZ4gJqx0UiKw7t8Huu7uHPMArLynVtfkf3VrSQ@mail.gmail.com>
 <010f01744f11f9bf-c8729b02-d495-4f82-afe3-375a5565da65-000000@us-east-2.amazonses.com>
 <CAH6fHQ=fjP_iNmnwuj5BGDeJfWTN6arXzwmc_wcaz2Ai7aNw0w@mail.gmail.com>
 <CAAS+=P8Ca6Go8_Nv3AUTgHLmVcCuuBPG+C0URJaXFY57fyNe1Q@mail.gmail.com>
 <CAH6fHQnwTjjka26-HCxVCcjdYH79fAZZZ4W8PB326py47f+j7A@mail.gmail.com>
 <010f0174550bef74-3697dc03-2dad-48dd-a1c8-47bee8d3a38a-000000@us-east-2.amazonses.com>
 <CAGK9nuqAs=NPP9NOY+t+aJ1NTZKL_2Cb7+8bYhAf-0fFaOWSMQ@mail.gmail.com>
 <010f01745522100a-5305b2d6-3a0c-4fe6-ad6c-fce1220af53d-000000@us-east-2.amazonses.com>
 <CAGK9nupUganbwfj51yV=O0AKEKCgpjkygj9t_AXyaV=Kv8KDdQ@mail.gmail.com>
 <CAF7SUTSydB+Pc_n1CkOsWAHEZ3RFK8q2xAZZqQiH10ue6AJVKA@mail.gmail.com>
 <CAD34_kJ1auApk73hNmZMv8nBMP8yew+goGirfX2Lk-jMOrRfpg@mail.gmail.com>
 <CAH6fHQnNyjJqbeSsUkewJXHrye_5VFa0kbfaFEXLbY03wK1aMQ@mail.gmail.com>
 <CAGK9nur-ASuiQHaH5c8e2+_-z6T_X-159e0W3LPGC4JYpZ9fNA@mail.gmail.com>
Message-ID: <CAH6fHQmV=6cQQKJnMsscLF7tRjbkhSiNWhq2vVhnhFTNF1=wQQ@mail.gmail.com>

On Fri, Sep 4, 2020 at 5:47 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

Yes
>
Interesting. Thanks.

Personally, I don’t really know how to resolve the tension between the
outer pattern saying: I *really* want to be lazy; and uniformity with the
unlifted-variable-binding case.

The point about b

b = let ~(MkX z) = undefined in ()

Is that it *cannot* do anything else than force the pattern. Because b is
an unlifted variable, it doesn’t contain a thunk. In other words, we can
read it as the pattern being lazy, but it being immediately forced. Pretty
much as in:

let (x,y) = undefined in x `seq` ()

My intuition would be that

let (x, (# #)) = (1, undefined) in ()

converges, while

let (x, (# #)) = (1, undefined) in x `seq` ()

diverges.

But I’m not exactly sure how to explain this rule succinctly. And I’m not
sure it would be quite as intuitive to anybody. For starters, it seems to
depart significantly from Iavor’s intuition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200907/af8f03c5/attachment.html>

From simonpj at microsoft.com  Mon Sep  7 12:09:10 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Sep 2020 12:09:10 +0000
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
Message-ID: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>

I’m a bit late to this debate, but here are a few thoughts.


  1.  “Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the binding is strict.”    Not only is this rule simple and consistent, it is also necessary: we cannot bind a variable of unlifted type to a thunk.   So any new rule must include this, and maybe add something extra, complicating the language.


  1.  All lazy pattern bindings go via an intermediate tuple.  If you write
(Just x, [y]) = e
then you get
t = case e of (Just x, [y]) -> (x,y)
x = fst t
y = snd t
The pattern can be complex and we don’t want to unpack it many times.  Moreover, the semantics says that it must be fully matched, so even if you just want ‘x’, you must check that the second component of the pair is indeed a singleton list.

So the “going via a tuple” part is nothing special about unboxed tuples – it simply holds for all lazy pattern bindings.


  1.  I don’t understand the details of Iavor’s proposal to add that “unlifted patterns are strict”, in addition to (1).  Do you mean “any sub-pattern of the LHS has an unlifted type”?  So
Just (# a,b #) = e
would be strict.   And even
MkT _ = e
would be strict if   data T = MkT (# Int,Int #)


  1.  Anything we do *must* scale to when we have user-defined unlifted data types (a current GHC Proposal)

TL;DR.  At the moment a change does not look attractive to me.  I could live with a warning for *outermost* unboxed tuples (or in general a constructor of an unlifted data type), suggesting to add a “!” or a “~” to make the intent clear.

Simon



From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 02 September 2020 14:47
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: Re: Implicit reboxing of unboxed tuple in let-patterns




On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:

Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know what the semantics of these ought to be. It does look like an interesting can of worms. How do they currently desugar?

Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the pattern is an unlifter-var pattern and is strict. The pattern must be banged, unless the bound variable is not nested. This rule is consistent across all features.

This thread is suggesting to add a special case -- one that seems to match intuition, but it's still a special case. And my question is: should the special case be for unboxed tuples? or should the special case be for any pattern whose overall type is unlifted?

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200907/968914e3/attachment.html>

From iavor.diatchki at gmail.com  Mon Sep  7 19:45:36 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Mon, 7 Sep 2020 12:45:36 -0700
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>

On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

>
>
>
>    1. I don’t understand the details of Iavor’s proposal to add that
>    “unlifted patterns are strict”, in addition to (1).  Do you mean “any
>    sub-pattern of the LHS has an unlifted type”? I think this is fully
>    compatible with unlifted user defined data
>
> Just (# a,b #) = e
>
> would be strict.   And even
>
> MkT _ = e
>
> would be strict if   data T = MkT (# Int,Int #)
>
>
>

Yes, the first one would be strict up to the tuple, and the second one
would also be strict.  I think this is the consistent way to interpret your
rule (1) that unlifted bindings are always strict, and it shouldn't really
matter if you used a variable pattern, or a wild card pattern.  I don't
think there's any other part of the language where replacing a `_` with an
unused name changes the semantics of the program, and I don't think it
should in this case either.

Just to be fully explicit, the thing I find odd with GHC's current behavior
is that these two are different:

let MkT x = undefined in ()       --> undefined
let MkT _ = undefined in ()       --> ()

Even more explicitly:
let (_ :: Int#) = undefined in ()   --> ()    -- the value `undefined` is
not representable in type `Int#` but GHC is happy to proceed because it
doesn't need to represent it
let (x :: Int#) = undefined in ()    --> ()   -- same situation, but now
GHC is strict, even though it still doesn't need to represent the value.

I think that the consistent behavior is for all of these to diverge,
because laziness does not mix with unlfited values, at least in the
presence of non-termination.

-Iavor










>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Richard
> Eisenberg
> *Sent:* 02 September 2020 14:47
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Cc:* GHC developers <ghc-devs at haskell.org>
> *Subject:* Re: Implicit reboxing of unboxed tuple in let-patterns
>
>
>
>
>
>
>
> On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>
>
> Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know
> what the semantics of these ought to be. It does look like an interesting
> can of worms. How do they currently desugar?
>
>
>
> Right now, there is one rule: if the type of any variable bound in the
> pattern is unlifted, then the pattern is an unlifter-var pattern and is
> strict. The pattern must be banged, unless the bound variable is not
> nested. This rule is consistent across all features.
>
>
>
> This thread is suggesting to add a special case -- one that seems to match
> intuition, but it's still a special case. And my question is: should the
> special case be for unboxed tuples? or should the special case be for any
> pattern whose overall type is unlifted?
>
>
>
> 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/20200907/c03150b8/attachment.html>

From simonpj at microsoft.com  Mon Sep  7 22:01:55 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 7 Sep 2020 22:01:55 +0000
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
Message-ID: <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>

I think this is the consistent way to interpret your rule (1) that unlifted bindings are always strict

But that’s not what rule (1) says.  It says that a pattern binding is strict iff it binds a variable of unlifted type.

Now I think we agree that your proposal says that a pattern binding is strict iff it or any of its sub-patterns has unlifted type, including wild-cards, variables, and constructor patterns; in fact any sub-pattern.   Call that (2).

So

  *   (1) is necessary.
  *   (2) is strictly stronger, and will make fewer program defined.  But is perhaps less surprising.

I think you could make a proposal out of that if you wanted.  I can’t decide if I like it, myself, but I think that it, too, is simple and consistent.

Simon

From: Iavor Diatchki <iavor.diatchki at gmail.com>
Sent: 07 September 2020 20:46
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Richard Eisenberg <rae at richarde.dev>; Spiwack, Arnaud <arnaud.spiwack at tweag.io>; GHC developers <ghc-devs at haskell.org>
Subject: Re: !RE: Implicit reboxing of unboxed tuple in let-patterns



On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:



  1.  I don’t understand the details of Iavor’s proposal to add that “unlifted patterns are strict”, in addition to (1).  Do you mean “any sub-pattern of the LHS has an unlifted type”? I think this is fully compatible with unlifted user defined data
Just (# a,b #) = e
would be strict.   And even
MkT _ = e
would be strict if   data T = MkT (# Int,Int #)


Yes, the first one would be strict up to the tuple, and the second one would also be strict.  I think this is the consistent way to interpret your rule (1) that unlifted bindings are always strict, and it shouldn't really matter if you used a variable pattern, or a wild card pattern.  I don't think there's any other part of the language where replacing a `_` with an unused name changes the semantics of the program, and I don't think it should in this case either.

Just to be fully explicit, the thing I find odd with GHC's current behavior is that these two are different:

let MkT x = undefined in ()       --> undefined
let MkT _ = undefined in ()       --> ()

Even more explicitly:
let (_ :: Int#) = undefined in ()   --> ()    -- the value `undefined` is not representable in type `Int#` but GHC is happy to proceed because it doesn't need to represent it
let (x :: Int#) = undefined in ()    --> ()   -- same situation, but now GHC is strict, even though it still doesn't need to represent the value.

I think that the consistent behavior is for all of these to diverge, because laziness does not mix with unlfited values, at least in the presence of non-termination.

-Iavor










From: ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Richard Eisenberg
Sent: 02 September 2020 14:47
To: Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>>
Cc: GHC developers <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
Subject: Re: Implicit reboxing of unboxed tuple in let-patterns



On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io<mailto:arnaud.spiwack at tweag.io>> wrote:

Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know what the semantics of these ought to be. It does look like an interesting can of worms. How do they currently desugar?

Right now, there is one rule: if the type of any variable bound in the pattern is unlifted, then the pattern is an unlifter-var pattern and is strict. The pattern must be banged, unless the bound variable is not nested. This rule is consistent across all features.

This thread is suggesting to add a special case -- one that seems to match intuition, but it's still a special case. And my question is: should the special case be for unboxed tuples? or should the special case be for any pattern whose overall type is unlifted?

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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b8984af610438e315a08d853669e2b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351047493622347&sdata=mlcv1AZBJ%2FHQYDQtS7NPQ5YnbhQA17tWx9fzoVe8Gic%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200907/2a3c7163/attachment.html>

From simonpj at microsoft.com  Tue Sep  8 10:41:13 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 8 Sep 2020 10:41:13 +0000
Subject: WebUI for GHC/Haskell tooling (eventlog)
In-Reply-To: <CANjChEqhfmbN_BU1cm_ja0fWMu1Sgp0JsrAVdvXucx_W3e6gwA@mail.gmail.com>
References: <CANjChEqhfmbN_BU1cm_ja0fWMu1Sgp0JsrAVdvXucx_W3e6gwA@mail.gmail.com>
Message-ID: <VI1PR83MB0429A5F077837FA9CFD8FF3BAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Csaba

I don’t know anything useful about tooling, WebUI, eventlog2html, etc.   But I do know that these things are important, so thank you so much for working on them!

I assume you in touch with the (new, unified) team working on the Haskell IDE?

Thanks again

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Csaba Hruska
Sent: 31 August 2020 19:30
To: GHC developers <ghc-devs at haskell.org>
Subject: WebUI for GHC/Haskell tooling (eventlog)

Hello,

I've written a blog post<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fposts%2F41065262&data=02%7C01%7Csimonpj%40microsoft.com%7C4abcd97d661e4fcbad2208d84ddbf825%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344954440665978&sdata=nhyZLT7K1zfDsa3CT%2BwOSe1DTYFQYKIWViDQiyKC7yY%3D&reserved=0> about my WebUI based eventlog related tool.
It is also related to eventlog2html and ghc-debug.
I'm interested in your opinion and ideas related to ghc debug/profiling tooling.
If you have time please read the post and it would be great to hear some positive or negative feedback from you. It would be great to discuss this topic with you.

Thanks,
Csaba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200908/b87ada55/attachment.html>

From davide at well-typed.com  Tue Sep  8 11:35:51 2020
From: davide at well-typed.com (David Eichmann)
Date: Tue, 8 Sep 2020 12:35:51 +0100
Subject: WebUI for GHC/Haskell tooling (eventlog)
In-Reply-To: <VI1PR83MB0429A5F077837FA9CFD8FF3BAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <CANjChEqhfmbN_BU1cm_ja0fWMu1Sgp0JsrAVdvXucx_W3e6gwA@mail.gmail.com>
 <VI1PR83MB0429A5F077837FA9CFD8FF3BAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <3a391736-d0d7-6b3d-dab6-1e330a8104e7@well-typed.com>

Csaba

It's really cool to see your work. Well-Typed and Hasura have recently 
started collaborating on some tooling (have a look at the announcement 
[1]). We are planning on taking the `ghc-debug` approach that you 
touched on at the end of your blog post, Csaba. While our approaches may 
be slightly different, we should keep in contact. Perhaps we'll be able 
to benefit from each other's work.

-David E

[1] 
https://hasura.io/blog/partnering-with-well-typed-and-investing-in-the-haskell-open-source-community/

On 9/8/20 11:41 AM, Simon Peyton Jones via ghc-devs wrote:
>
> Csaba
>
> I don’t know anything useful about tooling, WebUI, eventlog2html, 
> etc.   But I do know that these things are important, so thank you so 
> much for working on them!
>
> I assume you in touch with the (new, unified) team working on the 
> Haskell IDE?
>
> Thanks again
>
> Simon
>
> *From:*ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Csaba Hruska
> *Sent:* 31 August 2020 19:30
> *To:* GHC developers <ghc-devs at haskell.org>
> *Subject:* WebUI for GHC/Haskell tooling (eventlog)
>
> Hello,
>
> I've written ablog post 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fposts%2F41065262&data=02%7C01%7Csimonpj%40microsoft.com%7C4abcd97d661e4fcbad2208d84ddbf825%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344954440665978&sdata=nhyZLT7K1zfDsa3CT%2BwOSe1DTYFQYKIWViDQiyKC7yY%3D&reserved=0> 
> about my WebUI based eventlog related tool.
>
> It is also related to eventlog2html and ghc-debug.
>
> I'm interested in your opinion and ideas related to ghc 
> debug/profiling tooling.
>
> If you have time please read the post and it would be great to hear 
> some positive or negative feedback from you. It would be great to 
> discuss this topic with you.
>
> Thanks,
>
> Csaba
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
David Eichmann, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200908/e871d44a/attachment-0001.html>

From moritz.angermann at gmail.com  Wed Sep  9 14:17:48 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 9 Sep 2020 22:17:48 +0800
Subject: non-threaded rts and CollectGarbage
Message-ID: <CAKfdd-z_FX486SbaTKgtcjYK-W1FSrrMJEirZ5yZ+PAuz8BSDA@mail.gmail.com>

Hi there!

in the non-threaded rts we use itimer to do light weight scheduling of
threads via SIGALRM signals.  I'm seeing quite a bit of heap corruption on
aarch64, and it appears that I also see a lot of signal handling in the GC,
for example during evacuate.

Is there a fundamental reason why we can't just disable the timer during GC?

Cheers,
 Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200909/e7b7842b/attachment.html>

From arnaud.spiwack at tweag.io  Thu Sep 10 09:16:30 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 10 Sep 2020 11:16:30 +0200
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
 <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQ=qo34oED_hqykeDFTmqAvKt0TNmb208Jn5x20U6hhj+g@mail.gmail.com>

One thing that I had missed, until Simon pointed it out, is that in a let
pat = … expression, only the outermost pattern of pat is lazy. So

let (x,Just y) = (1, undefined) in x `seq` ()

Diverges. (whereas let (x,~(Just y)) = (1, undefined) in x `seq` ())
doesn’t).

So, really, we are only speaking of the outermost pattern, which does
simplify the discussion a little.

I don’t think that I share Iavor’s concern. In fact, I’ve got to say that I
personally don’t see (1) as meaning that the pattern is actually strict. I
just see a lazy pattern which happens to be immediately forced, because an
unlifted variable is bound. In this view, it doesn’t follow that the
presence of some unlifted pattern deep inside a lazy pattern ought to force
the pattern.

However, if the outermost pattern is unlifted, then it’s most likely that
it is not intended for the pattern to be lazy. From there, I see four ways
forward:

   1. Make let pat = … strict if the outermost pattern is unlifted
   2. Make let pat = … emit a warning if the outermost pattern is unlifted,
   but not explicitly banged.
   3. Decide that I’m mistaken, and that the current design is fine
   4. Decide that I’m mistaken, and that Iavor’s design it best

What do you think? I’ll try and make a proposal soon (unless (3) is too
popular for a proposal to be worth it).

On Tue, Sep 8, 2020 at 12:02 AM Simon Peyton Jones simonpj at microsoft.com
<http://mailto:simonpj at microsoft.com> wrote:

I think this is the consistent way to interpret your rule (1) that unlifted
> bindings are always strict
>
>
>
> But that’s not what rule (1) says.  It says that *a pattern binding is
> strict iff it binds a variable of unlifted type*.
>
>
>
> Now I think we agree that your proposal says that *a pattern binding is
> strict iff it or any of its sub-patterns has unlifted type, *including
> wild-cards, variables, and constructor patterns; in fact *any*
> sub-pattern.   Call that (2).
>
>
>
> So
>
>    - (1) is *necessary*.
>    - (2) is strictly stronger, and will make fewer program defined.  But
>    is perhaps less surprising.
>
>
>
> I think you could make a proposal out of that if you wanted.  I can’t
> decide if I like it, myself, but I think that it, too, is simple and
> consistent.
>
>
> Simon
>
>
>
> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Sent:* 07 September 2020 20:46
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Richard Eisenberg <rae at richarde.dev>; Spiwack, Arnaud <
> arnaud.spiwack at tweag.io>; GHC developers <ghc-devs at haskell.org>
> *Subject:* Re: !RE: Implicit reboxing of unboxed tuple in let-patterns
>
>
>
>
>
>
>
> On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
>
>
>
>
>    1. I don’t understand the details of Iavor’s proposal to add that
>    “unlifted patterns are strict”, in addition to (1).  Do you mean “any
>    sub-pattern of the LHS has an unlifted type”? I think this is fully
>    compatible with unlifted user defined data
>
> Just (# a,b #) = e
>
> would be strict.   And even
>
> MkT _ = e
>
> would be strict if   data T = MkT (# Int,Int #)
>
>
>
>
>
> Yes, the first one would be strict up to the tuple, and the second one
> would also be strict.  I think this is the consistent way to interpret your
> rule (1) that unlifted bindings are always strict, and it shouldn't really
> matter if you used a variable pattern, or a wild card pattern.  I don't
> think there's any other part of the language where replacing a `_` with an
> unused name changes the semantics of the program, and I don't think it
> should in this case either.
>
>
>
> Just to be fully explicit, the thing I find odd with GHC's current
> behavior is that these two are different:
>
>
>
> let MkT x = undefined in ()       --> undefined
>
> let MkT _ = undefined in ()       --> ()
>
>
>
> Even more explicitly:
>
> let (_ :: Int#) = undefined in ()   --> ()    -- the value `undefined` is
> not representable in type `Int#` but GHC is happy to proceed because it
> doesn't need to represent it
>
> let (x :: Int#) = undefined in ()    --> ()   -- same situation, but now
> GHC is strict, even though it still doesn't need to represent the value.
>
>
>
> I think that the consistent behavior is for all of these to diverge,
> because laziness does not mix with unlfited values, at least in the
> presence of non-termination.
>
>
>
> -Iavor
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Richard
> Eisenberg
> *Sent:* 02 September 2020 14:47
> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> *Cc:* GHC developers <ghc-devs at haskell.org>
> *Subject:* Re: Implicit reboxing of unboxed tuple in let-patterns
>
>
>
>
>
>
>
> On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
>
>
> Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know
> what the semantics of these ought to be. It does look like an interesting
> can of worms. How do they currently desugar?
>
>
>
> Right now, there is one rule: if the type of any variable bound in the
> pattern is unlifted, then the pattern is an unlifter-var pattern and is
> strict. The pattern must be banged, unless the bound variable is not
> nested. This rule is consistent across all features.
>
>
>
> This thread is suggesting to add a special case -- one that seems to match
> intuition, but it's still a special case. And my question is: should the
> special case be for unboxed tuples? or should the special case be for any
> pattern whose overall type is unlifted?
>
>
>
> Richard
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b8984af610438e315a08d853669e2b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351047493622347&sdata=mlcv1AZBJ%2FHQYDQtS7NPQ5YnbhQA17tWx9fzoVe8Gic%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/0fe4ddc0/attachment.html>

From sgraf1337 at gmail.com  Thu Sep 10 13:12:16 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 10 Sep 2020 15:12:16 +0200
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...
Message-ID: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>

Hey Sylvain,

In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971 I had to fight
once more with the transitive dependency set of the parser, the minimality
of which is crucial for ghc-lib-parser
<https://hackage.haskell.org/package/ghc-lib-parser> and tested by the
CountParserDeps test.

I discovered that I need to make (parts of) `DsM` abstract, because it is
transitively imported from the Parser for example through Parser.y ->
Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
Since you are our mastermind behind the "Tame DynFlags" initiative, I'd
like to hear your opinion on where progress can be/is made on that front.

I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961 and
https://gitlab.haskell.org/ghc/ghc/-/issues/11301 which ask a related, but
different question: They want a DynFlags-free interface, but I even want a
DynFlags-free *module*.

Would you say it's reasonable to abstract the definition of `PState` over
the `DynFlags` type? I think it's only used for pretty-printing messages,
which is one of your specialties (the treatment of DynFlags in there, at
least).
Anyway, can you think of or perhaps point me to an existing road map on
that issue?

Thank you!
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/a9983d8d/attachment.html>

From simonpj at microsoft.com  Thu Sep 10 13:16:43 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 10 Sep 2020 13:16:43 +0000
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
Message-ID: <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>

And for sure the *parser* should not depend on the *desugarer* and *typechecker*.   (Which it does, as described below.)

S

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Sebastian Graf
Sent: 10 September 2020 14:12
To: Sylvain Henry <sylvain at haskus.fr>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

Hey Sylvain,

In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0> I had to fight once more with the transitive dependency set of the parser, the minimality of which is crucial for ghc-lib-parser<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0> and tested by the CountParserDeps test.

I discovered that I need to make (parts of) `DsM` abstract, because it is transitively imported from the Parser for example through Parser.y -> Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
Since you are our mastermind behind the "Tame DynFlags" initiative, I'd like to hear your opinion on where progress can be/is made on that front.

I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0> and https://gitlab.haskell.org/ghc/ghc/-/issues/11301<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0> which ask a related, but different question: They want a DynFlags-free interface, but I even want a DynFlags-free *module*.

Would you say it's reasonable to abstract the definition of `PState` over the `DynFlags` type? I think it's only used for pretty-printing messages, which is one of your specialties (the treatment of DynFlags in there, at least).
Anyway, can you think of or perhaps point me to an existing road map on that issue?

Thank you!
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/5d4862e8/attachment.html>

From sylvain at haskus.fr  Thu Sep 10 15:24:07 2020
From: sylvain at haskus.fr (Sylvain Henry)
Date: Thu, 10 Sep 2020 17:24:07 +0200
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
Message-ID: <883fcdeb-c0dc-3532-469c-168f41af6cf0@haskus.fr>

Hi Sebastian,

Last month I tried to make a DynFlags-free parser. The branch is here: 
https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20/dynflags/parser 
(doesn't build iirc)

1) The input of the parser is almost DynFlags-free thanks to Alec's 
patch [1]. On that front, we just have to move `mkParserFlags` out of 
GHC.Parser. I would put it alongside other functions generating config 
datatypes from DynFlags in GHC.Driver.Config (added yesterday). It's 
done in my branch and it only required a bit of plumbing to fix 
`lexTokenStream` iirc.

2) The output of the parser is the issue, as you point out. The main 
issue is that it uses SDoc/ErrMsg which are dependent on DynFlags.

In the branch I've tried to avoid the use of SDoc by using ADTs to 
return errors and warnings so that the client of the parser would be 
responsible for converting them into SDoc if needed. This is the 
approach that we would like to generalize [2]. The ADT would look like 
[3] and the pretty-printing module like [4]. The idea was that 
ghc-lib-parser wouldn't integrate the pretty-printing module to avoid 
the dependencies.

I think it's the best interface (for IDEs and other tools) so we just 
have to complete the work :). The branch stalled because I've tried to 
avoid SDoc even in the pretty-printing module and used Doc instead of 
SDoc but it wasn't a good idea... I'll try to resume the work soon.

In the meantime I've been working on making Outputable/SDoc independent 
of DynFlags. If we merge [5] in some form then the last place where we 
use `sdocWithDynFlags` will be in CLabel's Outputable instance (to fix 
this I think we could just depend on the PprStyle (Asm or C) instead of 
querying the backend in the DynFlags). This could be another approach to 
make the parser almost as it is today independent of DynFlags. A 
side-effect of this work is that ghc-lib-parser could include the 
pretty-printing module too.

So to answer your question:

 > Would you say it's reasonable to abstract the definition of `PState` 
over the `DynFlags` type?

We're close to remove the dependence on DynFlags so I would prefer this 
instead of trying to abstract over it.

The roadmap:

1. Make Outputable/SDoc independent of DynFlags
1.1 Remove sdocWithDynFlags used to query the platform (!3972)
1.2 Remove sdocWithDynFlags used to query the backend in CLabel's 
Outputable instance
1.3 Remove sdocWithDynFlags
2. Move mkParserFlags from GHC.Parser to GHC.Driver.Config
3. (Make the parser use ADTs to return errors/warnings)

Cheers,
Sylvain

[1] 
https://gitlab.haskell.org/ghc/ghc/-/commit/469fe6133646df5568c9486de2202124cb734242
[2] https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
[3] 
https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors.hs
[4] 
https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors/Ppr.hs
[5] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3972


On 10/09/2020 15:12, Sebastian Graf wrote:
> Hey Sylvain,
>
> In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971 I had to 
> fight once more with the transitive dependency set of the parser, the 
> minimality of which is crucial for ghc-lib-parser 
> <https://hackage.haskell.org/package/ghc-lib-parser> and tested by the 
> CountParserDeps test.
>
> I discovered that I need to make (parts of) `DsM` abstract, because it 
> is transitively imported from the Parser for example through Parser.y 
> -> Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
> Since you are our mastermind behind the "Tame DynFlags" initiative, 
> I'd like to hear your opinion on where progress can be/is made on that 
> front.
>
> I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961 and 
> https://gitlab.haskell.org/ghc/ghc/-/issues/11301 which ask a related, 
> but different question: They want a DynFlags-free interface, but I 
> even want a DynFlags-free *module*.
>
> Would you say it's reasonable to abstract the definition of `PState` 
> over the `DynFlags` type? I think it's only used for pretty-printing 
> messages, which is one of your specialties (the treatment of DynFlags 
> in there, at least).
> Anyway, can you think of or perhaps point me to an existing road map 
> on that issue?
>
> Thank you!
> Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/ff707722/attachment.html>

From sgraf1337 at gmail.com  Thu Sep 10 15:27:01 2020
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Thu, 10 Sep 2020 17:27:01 +0200
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <883fcdeb-c0dc-3532-469c-168f41af6cf0@haskus.fr>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <883fcdeb-c0dc-3532-469c-168f41af6cf0@haskus.fr>
Message-ID: <CAAS+=P8aF0w2e+3H-ty5GeMr5eOojKiF+Rky-6vwzd5N16ZbQA@mail.gmail.com>

Hi Sylvain,

Thanks, that answers all my questions! Keep up the great work.

Cheers
Sebastian

Am Do., 10. Sept. 2020 um 17:24 Uhr schrieb Sylvain Henry <sylvain at haskus.fr
>:

> Hi Sebastian,
>
> Last month I tried to make a DynFlags-free parser. The branch is here:
> https://gitlab.haskell.org/hsyl20/ghc/-/commits/hsyl20/dynflags/parser
> (doesn't build iirc)
>
> 1) The input of the parser is almost DynFlags-free thanks to Alec's patch
> [1]. On that front, we just have to move `mkParserFlags` out of GHC.Parser.
> I would put it alongside other functions generating config datatypes from
> DynFlags in GHC.Driver.Config (added yesterday). It's done in my branch and
> it only required a bit of plumbing to fix `lexTokenStream` iirc.
>
> 2) The output of the parser is the issue, as you point out. The main issue
> is that it uses SDoc/ErrMsg which are dependent on DynFlags.
>
> In the branch I've tried to avoid the use of SDoc by using ADTs to return
> errors and warnings so that the client of the parser would be responsible
> for converting them into SDoc if needed. This is the approach that we would
> like to generalize [2]. The ADT would look like [3] and the pretty-printing
> module like [4]. The idea was that ghc-lib-parser wouldn't integrate the
> pretty-printing module to avoid the dependencies.
>
> I think it's the best interface (for IDEs and other tools) so we just have
> to complete the work :). The branch stalled because I've tried to avoid
> SDoc even in the pretty-printing module and used Doc instead of SDoc but it
> wasn't a good idea... I'll try to resume the work soon.
>
> In the meantime I've been working on making Outputable/SDoc independent of
> DynFlags. If we merge [5] in some form then the last place where we use
> `sdocWithDynFlags` will be in CLabel's Outputable instance (to fix this I
> think we could just depend on the PprStyle (Asm or C) instead of querying
> the backend in the DynFlags). This could be another approach to make the
> parser almost as it is today independent of DynFlags. A side-effect of this
> work is that ghc-lib-parser could include the pretty-printing module too.
>
> So to answer your question:
>
> > Would you say it's reasonable to abstract the definition of `PState`
> over the `DynFlags` type?
>
> We're close to remove the dependence on DynFlags so I would prefer this
> instead of trying to abstract over it.
>
> The roadmap:
>
> 1. Make Outputable/SDoc independent of DynFlags
> 1.1 Remove sdocWithDynFlags used to query the platform (!3972)
> 1.2 Remove sdocWithDynFlags used to query the backend in CLabel's
> Outputable instance
> 1.3 Remove sdocWithDynFlags
> 2. Move mkParserFlags from GHC.Parser to GHC.Driver.Config
> 3. (Make the parser use ADTs to return errors/warnings)
>
> Cheers,
> Sylvain
>
> [1]
> https://gitlab.haskell.org/ghc/ghc/-/commit/469fe6133646df5568c9486de2202124cb734242
> [2]
> https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values
> [3]
> https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors.hs
> [4]
> https://gitlab.haskell.org/hsyl20/ghc/-/blob/hsyl20/dynflags/parser/compiler/GHC/Parser/Errors/Ppr.hs
> [5] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3972
>
>
> On 10/09/2020 15:12, Sebastian Graf wrote:
>
> Hey Sylvain,
>
> In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971 I had to
> fight once more with the transitive dependency set of the parser, the
> minimality of which is crucial for ghc-lib-parser
> <https://hackage.haskell.org/package/ghc-lib-parser> and tested by the
> CountParserDeps test.
>
> I discovered that I need to make (parts of) `DsM` abstract, because it is
> transitively imported from the Parser for example through Parser.y ->
> Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
> Since you are our mastermind behind the "Tame DynFlags" initiative, I'd
> like to hear your opinion on where progress can be/is made on that front.
>
> I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961 and
> https://gitlab.haskell.org/ghc/ghc/-/issues/11301 which ask a related,
> but different question: They want a DynFlags-free interface, but I even
> want a DynFlags-free *module*.
>
> Would you say it's reasonable to abstract the definition of `PState` over
> the `DynFlags` type? I think it's only used for pretty-printing messages,
> which is one of your specialties (the treatment of DynFlags in there, at
> least).
> Anyway, can you think of or perhaps point me to an existing road map on
> that issue?
>
> Thank you!
> Sebastian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/97200ee0/attachment.html>

From iavor.diatchki at gmail.com  Thu Sep 10 16:05:20 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 10 Sep 2020 09:05:20 -0700
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAH6fHQ=qo34oED_hqykeDFTmqAvKt0TNmb208Jn5x20U6hhj+g@mail.gmail.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
 <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=qo34oED_hqykeDFTmqAvKt0TNmb208Jn5x20U6hhj+g@mail.gmail.com>
Message-ID: <CAGK9nuqp5tf4wRT+WBSnyY-_jkk9KQzAhwCiLy-QktVbY_Yw4g@mail.gmail.com>

Hello,

there are multiple things being discussed here, which I think is leading to
some confusion, in particular:
   1. How do pattern bindings work in normal Haskell?  It is not the case
that only the outer pattern is lazy---when the patterns are matched depends
on how the bound variables are used.  I don't think we need to make changes
here.
   2. How should patterns on unlifted types work in pattern bindings, both
nested and at the top level?  This is what started this discussion
originally.
   3. How should nested bang patterns work in pattern bindings?  This came
out from Richard's examples in response to my suggestion on how (2) might
work.
   4. Should you always be able to replace `_` with an unused name without
changing the semantics, which also came from Richard's examples.

Going backward, here are my thoughts:
  4. the answer to this should be `yes`, as it would make it consistent
with how the rest of the language works.
  3. nested bang patterns in pattern bindings should count as "uses" of the
value and therefore should be strict.  For example if I write `let ( !x, !y
) = undefined in ()`, I think this should be equivalent to `let (x,y) =
undefined in x `seq` y `seq` ()`.  With the current behavior the bang
patterns don't do anything, while my guess would be that most people would
expect the suggested behavior instead.  As usual, we should not allow that
at the top level.
  2. I think that an unlifted pattern (meaning "a pattern on a value of an
unlifted type") that is only nested in other unlifted patterns should be
strict  This includes top-level bindings as a special case, as they are not
nested in anything.
    * For unlifted patterns nested in lifted patterns we have a choice:
         2.1 I suggested that, for simplicity, these should also be strict,
so that you could just say "all unlifted patterns are strict".   This would
mean that the containing (lifted) value would be always forced.
         2.2 I could also see a reasonable case being made for these not
forcing the evaluation of their containing value until the unlifted value
is demanded.   Perhaps this is more consistent with how the rest of the
language works, so I'd be on board with that choice too.

I think what I am suggesting is consistent with Arnaud's choice (1), except
it goes into a bit more details on how nested patterns should work.

Hope this clarifies things a bit,
-Iavor














On Thu, Sep 10, 2020 at 2:17 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> One thing that I had missed, until Simon pointed it out, is that in a let
> pat = … expression, only the outermost pattern of pat is lazy. So
>
> let (x,Just y) = (1, undefined) in x `seq` ()
>
> Diverges. (whereas let (x,~(Just y)) = (1, undefined) in x `seq` ())
> doesn’t).
>
> So, really, we are only speaking of the outermost pattern, which does
> simplify the discussion a little.
>
> I don’t think that I share Iavor’s concern. In fact, I’ve got to say that
> I personally don’t see (1) as meaning that the pattern is actually strict.
> I just see a lazy pattern which happens to be immediately forced, because
> an unlifted variable is bound. In this view, it doesn’t follow that the
> presence of some unlifted pattern deep inside a lazy pattern ought to force
> the pattern.
>
> However, if the outermost pattern is unlifted, then it’s most likely that
> it is not intended for the pattern to be lazy. From there, I see four ways
> forward:
>
>    1. Make let pat = … strict if the outermost pattern is unlifted
>    2. Make let pat = … emit a warning if the outermost pattern is
>    unlifted, but not explicitly banged.
>    3. Decide that I’m mistaken, and that the current design is fine
>    4. Decide that I’m mistaken, and that Iavor’s design it best
>
> What do you think? I’ll try and make a proposal soon (unless (3) is too
> popular for a proposal to be worth it).
>
> On Tue, Sep 8, 2020 at 12:02 AM Simon Peyton Jones simonpj at microsoft.com
> <http://mailto:simonpj at microsoft.com> wrote:
>
> I think this is the consistent way to interpret your rule (1) that
>> unlifted bindings are always strict
>>
>>
>>
>> But that’s not what rule (1) says.  It says that *a pattern binding is
>> strict iff it binds a variable of unlifted type*.
>>
>>
>>
>> Now I think we agree that your proposal says that *a pattern binding is
>> strict iff it or any of its sub-patterns has unlifted type, *including
>> wild-cards, variables, and constructor patterns; in fact *any*
>> sub-pattern.   Call that (2).
>>
>>
>>
>> So
>>
>>    - (1) is *necessary*.
>>    - (2) is strictly stronger, and will make fewer program defined.  But
>>    is perhaps less surprising.
>>
>>
>>
>> I think you could make a proposal out of that if you wanted.  I can’t
>> decide if I like it, myself, but I think that it, too, is simple and
>> consistent.
>>
>>
>> Simon
>>
>>
>>
>> *From:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> *Sent:* 07 September 2020 20:46
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Spiwack, Arnaud <
>> arnaud.spiwack at tweag.io>; GHC developers <ghc-devs at haskell.org>
>> *Subject:* Re: !RE: Implicit reboxing of unboxed tuple in let-patterns
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Sep 7, 2020 at 5:12 AM Simon Peyton Jones via ghc-devs <
>> ghc-devs at haskell.org> wrote:
>>
>>
>>
>>
>>
>>    1. I don’t understand the details of Iavor’s proposal to add that
>>    “unlifted patterns are strict”, in addition to (1).  Do you mean “any
>>    sub-pattern of the LHS has an unlifted type”? I think this is fully
>>    compatible with unlifted user defined data
>>
>> Just (# a,b #) = e
>>
>> would be strict.   And even
>>
>> MkT _ = e
>>
>> would be strict if   data T = MkT (# Int,Int #)
>>
>>
>>
>>
>>
>> Yes, the first one would be strict up to the tuple, and the second one
>> would also be strict.  I think this is the consistent way to interpret your
>> rule (1) that unlifted bindings are always strict, and it shouldn't really
>> matter if you used a variable pattern, or a wild card pattern.  I don't
>> think there's any other part of the language where replacing a `_` with an
>> unused name changes the semantics of the program, and I don't think it
>> should in this case either.
>>
>>
>>
>> Just to be fully explicit, the thing I find odd with GHC's current
>> behavior is that these two are different:
>>
>>
>>
>> let MkT x = undefined in ()       --> undefined
>>
>> let MkT _ = undefined in ()       --> ()
>>
>>
>>
>> Even more explicitly:
>>
>> let (_ :: Int#) = undefined in ()   --> ()    -- the value `undefined` is
>> not representable in type `Int#` but GHC is happy to proceed because it
>> doesn't need to represent it
>>
>> let (x :: Int#) = undefined in ()    --> ()   -- same situation, but now
>> GHC is strict, even though it still doesn't need to represent the value.
>>
>>
>>
>> I think that the consistent behavior is for all of these to diverge,
>> because laziness does not mix with unlfited values, at least in the
>> presence of non-termination.
>>
>>
>>
>> -Iavor
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Richard
>> Eisenberg
>> *Sent:* 02 September 2020 14:47
>> *To:* Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> *Cc:* GHC developers <ghc-devs at haskell.org>
>> *Subject:* Re: Implicit reboxing of unboxed tuple in let-patterns
>>
>>
>>
>>
>>
>>
>>
>> On Sep 2, 2020, at 9:39 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>
>>
>> Ooh… pattern synonyms for unboxed tuple. I must confess that I don't know
>> what the semantics of these ought to be. It does look like an interesting
>> can of worms. How do they currently desugar?
>>
>>
>>
>> Right now, there is one rule: if the type of any variable bound in the
>> pattern is unlifted, then the pattern is an unlifter-var pattern and is
>> strict. The pattern must be banged, unless the bound variable is not
>> nested. This rule is consistent across all features.
>>
>>
>>
>> This thread is suggesting to add a special case -- one that seems to
>> match intuition, but it's still a special case. And my question is: should
>> the special case be for unboxed tuples? or should the special case be for
>> any pattern whose overall type is unlifted?
>>
>>
>>
>> Richard
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ca1b8984af610438e315a08d853669e2b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351047493622347&sdata=mlcv1AZBJ%2FHQYDQtS7NPQ5YnbhQA17tWx9fzoVe8Gic%3D&reserved=0>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/918c44c7/attachment-0001.html>

From rae at richarde.dev  Thu Sep 10 16:18:32 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 10 Sep 2020 16:18:32 +0000
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAGK9nuqp5tf4wRT+WBSnyY-_jkk9KQzAhwCiLy-QktVbY_Yw4g@mail.gmail.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
 <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=qo34oED_hqykeDFTmqAvKt0TNmb208Jn5x20U6hhj+g@mail.gmail.com>
 <CAGK9nuqp5tf4wRT+WBSnyY-_jkk9KQzAhwCiLy-QktVbY_Yw4g@mail.gmail.com>
Message-ID: <010f017478cfb48b-c1db68d3-0d69-4528-b501-4b212667a6ab-000000@us-east-2.amazonses.com>

This whole area is clearly somewhat troublesome:

> On Sep 10, 2020, at 12:05 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> 3. nested bang patterns in pattern bindings should count as "uses" of the value and therefore should be strict.  For example if I write `let ( !x, !y ) = undefined in ()`, I think this should be equivalent to `let (x,y) = undefined in x `seq` y `seq` ()`.  With the current behavior the bang patterns don't do anything, while my guess would be that most people would expect the suggested behavior instead.  As usual, we should not allow that at the top level.

This isn't quite right.

Consider

> ex0 = let ( !x, !y ) = undefined in ()
> ex1 = let ( !x, !y ) = (5, undefined) in x
> ex2 = let ( !x, y )  = (5, undefined) in x

ex0 converges, because let-bindings are lazy by default.
ex1 diverges, because the bang on y means that, when the patten-match happens at all, x and y are bound strictly. So bangs *do* matter in nested patterns within pattern bindings. By contrast, ex2 converges.

Again, I'm not arguing in favor of the current behavior, but I want to make sure we're all as informed as possible in this debate.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/082d9672/attachment.html>

From iavor.diatchki at gmail.com  Thu Sep 10 16:38:39 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 10 Sep 2020 09:38:39 -0700
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <010f017478cfb48b-c1db68d3-0d69-4528-b501-4b212667a6ab-000000@us-east-2.amazonses.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
 <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=qo34oED_hqykeDFTmqAvKt0TNmb208Jn5x20U6hhj+g@mail.gmail.com>
 <CAGK9nuqp5tf4wRT+WBSnyY-_jkk9KQzAhwCiLy-QktVbY_Yw4g@mail.gmail.com>
 <010f017478cfb48b-c1db68d3-0d69-4528-b501-4b212667a6ab-000000@us-east-2.amazonses.com>
Message-ID: <CAGK9nuqLxuxrpcgKw+haq6SL51Am+ergZh2AapNWhK1Fh_Os_w@mail.gmail.com>

Ah, yes, quite right: since the projections match the whole patterns, the
bang patterns in a constructor would be forced as soon as one of the fields
in the constructor is used, so this also diverges:

ex3 = let (x, !y) = (5,undefined) in x

The rule is consistent, to me it just seems quite unintuitive.



On Thu, Sep 10, 2020 at 9:18 AM Richard Eisenberg <rae at richarde.dev> wrote:

> This whole area is clearly somewhat troublesome:
>
> On Sep 10, 2020, at 12:05 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> 3. nested bang patterns in pattern bindings should count as "uses" of the
> value and therefore should be strict.  For example if I write `let ( !x, !y
> ) = undefined in ()`, I think this should be equivalent to `let (x,y) =
> undefined in x `seq` y `seq` ()`.  With the current behavior the bang
> patterns don't do anything, while my guess would be that most people would
> expect the suggested behavior instead.  As usual, we should not allow that
> at the top level.
>
>
> This isn't quite right.
>
> Consider
>
> ex0 = let ( !x, !y ) = undefined in ()
> ex1 = let ( !x, !y ) = (5, undefined) in x
> ex2 = let ( !x, y )  = (5, undefined) in x
>
>
> ex0 converges, because let-bindings are lazy by default.
> ex1 diverges, because the bang on y means that, when the patten-match
> happens at all, x and y are bound strictly. So bangs *do* matter in nested
> patterns within pattern bindings. By contrast, ex2 converges.
>
> Again, I'm not arguing in favor of the current behavior, but I want to
> make sure we're all as informed as possible in this debate.
>
> Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200910/c6497aa9/attachment.html>

From cdsmith at gmail.com  Thu Sep 10 17:12:01 2020
From: cdsmith at gmail.com (Chris Smith)
Date: Thu, 10 Sep 2020 13:12:01 -0400
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAGK9nuqLxuxrpcgKw+haq6SL51Am+ergZh2AapNWhK1Fh_Os_w@mail.gmail.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
 <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=qo34oED_hqykeDFTmqAvKt0TNmb208Jn5x20U6hhj+g@mail.gmail.com>
 <CAGK9nuqp5tf4wRT+WBSnyY-_jkk9KQzAhwCiLy-QktVbY_Yw4g@mail.gmail.com>
 <010f017478cfb48b-c1db68d3-0d69-4528-b501-4b212667a6ab-000000@us-east-2.amazonses.com>
 <CAGK9nuqLxuxrpcgKw+haq6SL51Am+ergZh2AapNWhK1Fh_Os_w@mail.gmail.com>
Message-ID: <CAPq5PvJkZh6++nv1NV=U9L6d=2hDZnHSWwqX2Qa4s453HL1gAg@mail.gmail.com>

I agree that the strictness there was surprising, but I think this may be a
case where what is superficially expected is, in the end, inconsistent.

What about:

let ~(!x, !y) = undefined in ()

If nested bang patterns implied strictness of their parents, this valid
expression seems not to make any sense.  I can see a few ways to deal with
that, but none of them seem intuitive to me.

One could disallow it, and only allow strictness annotations on variables
rather than all patterns, but this sacrifices a lot of functionality to
avoid that surprise.  Alternatively, one could say that upward propagation
of strictness is only a default, but that definitely feels like a hack.  It
might make the original example behave as expected, but it is no longer for
the expected reasons, and suddenly there is something even more complex
going on.

I don't have a strong opinion here, but I think it's important to consider
more complex cases when making the decision.

On Thu, Sep 10, 2020, 12:39 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> Ah, yes, quite right: since the projections match the whole patterns, the
> bang patterns in a constructor would be forced as soon as one of the fields
> in the constructor is used, so this also diverges:
>
> ex3 = let (x, !y) = (5,undefined) in x
>
> The rule is consistent, to me it just seems quite unintuitive.
>
>
>
> On Thu, Sep 10, 2020 at 9:18 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> This whole area is clearly somewhat troublesome:
>>
>> On Sep 10, 2020, at 12:05 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>> 3. nested bang patterns in pattern bindings should count as "uses" of the
>> value and therefore should be strict.  For example if I write `let ( !x, !y
>> ) = undefined in ()`, I think this should be equivalent to `let (x,y) =
>> undefined in x `seq` y `seq` ()`.  With the current behavior the bang
>> patterns don't do anything, while my guess would be that most people would
>> expect the suggested behavior instead.  As usual, we should not allow that
>> at the top level.
>>
>>
>> This isn't quite right.
>>
>> Consider
>>
>> ex0 = let ( !x, !y ) = undefined in ()
>> ex1 = let ( !x, !y ) = (5, undefined) in x
>> ex2 = let ( !x, y )  = (5, undefined) in x
>>
>>
>> ex0 converges, because let-bindings are lazy by default.
>> ex1 diverges, because the bang on y means that, when the patten-match
>> happens at all, x and y are bound strictly. So bangs *do* matter in nested
>> patterns within pattern bindings. By contrast, ex2 converges.
>>
>> Again, I'm not arguing in favor of the current behavior, but I want to
>> make sure we're all as informed as possible in this debate.
>>
>> 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/20200910/2f566165/attachment.html>

From iavor.diatchki at gmail.com  Thu Sep 10 17:45:02 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 10 Sep 2020 10:45:02 -0700
Subject: !RE: Implicit reboxing of unboxed tuple in let-patterns
In-Reply-To: <CAPq5PvJkZh6++nv1NV=U9L6d=2hDZnHSWwqX2Qa4s453HL1gAg@mail.gmail.com>
References: <VI1PR83MB04293FEB72734E498BFE3570AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nurhQk7sNDjXpKRdbVQ_jAvM_80SfBi-iGD+WE+d2+nD4w@mail.gmail.com>
 <VI1PR83MB0429E21AC1D781DA810D9661AD280@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=qo34oED_hqykeDFTmqAvKt0TNmb208Jn5x20U6hhj+g@mail.gmail.com>
 <CAGK9nuqp5tf4wRT+WBSnyY-_jkk9KQzAhwCiLy-QktVbY_Yw4g@mail.gmail.com>
 <010f017478cfb48b-c1db68d3-0d69-4528-b501-4b212667a6ab-000000@us-east-2.amazonses.com>
 <CAGK9nuqLxuxrpcgKw+haq6SL51Am+ergZh2AapNWhK1Fh_Os_w@mail.gmail.com>
 <CAPq5PvJkZh6++nv1NV=U9L6d=2hDZnHSWwqX2Qa4s453HL1gAg@mail.gmail.com>
Message-ID: <CAGK9nuo9dW6K+jjhREpPJGCjZAgQaz1NPtXSj09JXRXoTqe5wA@mail.gmail.com>

I am not sure what you'd expect this to do, but under what I was suggesting
it would be equivalent to
`let ~(x,y) = undefined in x `seq` y `seq ()`

Obviously it would be nice to warn/report error that this is probably a
mistake, which seems pretty easy to do.
What useful functionality do you think is lost by this?

The main tricky case I can think of is the interaction with pattern
synonyms, as one would have to keep track of
strict bindings in those.




On Thu, Sep 10, 2020 at 10:12 AM Chris Smith <cdsmith at gmail.com> wrote:

> I agree that the strictness there was surprising, but I think this may be
> a case where what is superficially expected is, in the end, inconsistent.
>
> What about:
>
> let ~(!x, !y) = undefined in ()
>
> If nested bang patterns implied strictness of their parents, this valid
> expression seems not to make any sense.  I can see a few ways to deal with
> that, but none of them seem intuitive to me.
>
> One could disallow it, and only allow strictness annotations on variables
> rather than all patterns, but this sacrifices a lot of functionality to
> avoid that surprise.  Alternatively, one could say that upward propagation
> of strictness is only a default, but that definitely feels like a hack.  It
> might make the original example behave as expected, but it is no longer for
> the expected reasons, and suddenly there is something even more complex
> going on.
>
> I don't have a strong opinion here, but I think it's important to consider
> more complex cases when making the decision.
>
> On Thu, Sep 10, 2020, 12:39 PM Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> Ah, yes, quite right: since the projections match the whole patterns, the
>> bang patterns in a constructor would be forced as soon as one of the fields
>> in the constructor is used, so this also diverges:
>>
>> ex3 = let (x, !y) = (5,undefined) in x
>>
>> The rule is consistent, to me it just seems quite unintuitive.
>>
>>
>>
>> On Thu, Sep 10, 2020 at 9:18 AM Richard Eisenberg <rae at richarde.dev>
>> wrote:
>>
>>> This whole area is clearly somewhat troublesome:
>>>
>>> On Sep 10, 2020, at 12:05 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>>> wrote:
>>>
>>> 3. nested bang patterns in pattern bindings should count as "uses" of
>>> the value and therefore should be strict.  For example if I write `let (
>>> !x, !y ) = undefined in ()`, I think this should be equivalent to `let
>>> (x,y) = undefined in x `seq` y `seq` ()`.  With the current behavior the
>>> bang patterns don't do anything, while my guess would be that most people
>>> would expect the suggested behavior instead.  As usual, we should not allow
>>> that at the top level.
>>>
>>>
>>> This isn't quite right.
>>>
>>> Consider
>>>
>>> ex0 = let ( !x, !y ) = undefined in ()
>>> ex1 = let ( !x, !y ) = (5, undefined) in x
>>> ex2 = let ( !x, y )  = (5, undefined) in x
>>>
>>>
>>> ex0 converges, because let-bindings are lazy by default.
>>> ex1 diverges, because the bang on y means that, when the patten-match
>>> happens at all, x and y are bound strictly. So bangs *do* matter in nested
>>> patterns within pattern bindings. By contrast, ex2 converges.
>>>
>>> Again, I'm not arguing in favor of the current behavior, but I want to
>>> make sure we're all as informed as possible in this debate.
>>>
>>> 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/20200910/2ae223f1/attachment.html>

From michael.sperber at active-group.de  Fri Sep 11 14:24:05 2020
From: michael.sperber at active-group.de (michael.sperber at active-group.de)
Date: Fri, 11 Sep 2020 16:24:05 +0200
Subject: Simplifier vs. rules problem
Message-ID: <y9ly2lgfl2y.fsf@valmont.fritz.box>


I've been trying to make Conal's ConCat plugin work for polymorphic
code, and am running into some problems with the ghc doing that, and I'd
very much appreciate help with that.

Background: I'm trying to get -dcore-lint to flag when my actual problem
happens (has to do with dictionary construction, but it fails earlier
with another problem, which I think comes from the simplifier.

tl;dr: This transformation seems to me problematic:

https://ghc-compiler-notes.readthedocs.io/en/latest/notes/compiler/simplCore/Simplify.hs.html#note-case-to-let-transformation

The docs for the transformation say that it makes this replacement:

case a +# b of r -> …r… into let r = a +# b in …r…

But this creates a let binding with an unlifted binder, which the linter
does not like:

<no location info>: warning:
    [RHS of ... :: Int#]
    The type of this binder is unlifted: ...
    Binder's type: Int#

Arguably, this rule might expect the let to be inlined, but we're seeing
that the let stands, and the linter complains.

My immediate concern is getting around this problem somehow so I can run
the linter on later output of the simplifier.  Is there any way to do
this?  I.e. don't stop when the linter complains, somehow massage the
rules to work better - see below.  Any help would be much appreciated!
(I'm using ghc 8.8.3.)

More details:

The ConCat code has this rule:

"rebox2" [~0] (+#) = \ u# v# -> unboxI (addC (boxI u#, boxI v#))

It fires like this:

Rule fired
    Rule: rebox_2
    Module: (ConCat.Rebox)
    Before: GHC.Prim.+# ValArg 10# ValArg 1#
    After:  (\ (u#_aM4G :: GHC.Prim.Int#) (v#_aM4H :: GHC.Prim.Int#) ->
               ConCat.Rebox.unboxI
                 (ConCat.AltCat.addC
                    @ (->)
                    @ GHC.Types.Int
                    (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt)
                    (ConCat.Rebox.boxI u#_aM4G, ConCat.Rebox.boxI v#_aM4H)))
              10# 1#
    Cont:   Stop[BoringCtxt] GHC.Prim.Int#

... and comes out of the simplifier like this:

let {
  n1_sM4V :: GHC.Prim.Int#
  [LclId,
   Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False,
           WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110 0}]
  n1_sM4V
    = case ConCat.AltCat.addC
             @ (->)
             @ GHC.Types.Int
             (ConCat.Category.$fNumCat->a
                @ GHC.Types.Int GHC.Num.$fNumInt)
             (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#)
      of
      { GHC.Types.I# i#_aM4S ->
      i#_aM4S
      } } in
GHC.Types.I#
  (case ConCat.AltCat.addC
          @ (->)
          @ GHC.Types.Int
          (ConCat.Category.$fNumCat->a @ GHC.Types.Int GHC.Num.$fNumInt)
          (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#)
   of
   { GHC.Types.I# i#_aM4S ->
   i#_aM4S
   }) } in ...

Ironically, you can see that the simplifier already *has* inlined, just
not elided the (now dead) let binding yet, before the linter gets to it.

I've also attached a shorter source file with the relevant rules that
triggers the linter, albeit with a different message.

Richard Eisenberg, Gabor Greif, and Conal helped me get to this point.
Many thanks to them!

-- 
Regards,
Mike
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200911/2bab8dcb/attachment.ksh>

From simonpj at microsoft.com  Fri Sep 11 20:31:02 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 11 Sep 2020 20:31:02 +0000
Subject: Simplifier vs. rules problem
In-Reply-To: <y9ly2lgfl2y.fsf@valmont.fritz.box>
References: <y9ly2lgfl2y.fsf@valmont.fritz.box>
Message-ID: <VI1PR83MB0429FEE1CE7BA6575AD61072AD240@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Interesting. I have opened
https://gitlab.haskell.org/ghc/ghc/-/issues/18677
for this.

Simon

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of
|  michael.sperber at active-group.de
|  Sent: 11 September 2020 15:24
|  To: ghc-devs at haskell.org
|  Subject: Simplifier vs. rules problem
|  
|  
|  I've been trying to make Conal's ConCat plugin work for polymorphic
|  code, and am running into some problems with the ghc doing that, and
|  I'd
|  very much appreciate help with that.
|  
|  Background: I'm trying to get -dcore-lint to flag when my actual
|  problem
|  happens (has to do with dictionary construction, but it fails earlier
|  with another problem, which I think comes from the simplifier.
|  
|  tl;dr: This transformation seems to me problematic:
|  
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc-
|  compiler-
|  notes.readthedocs.io%2Fen%2Flatest%2Fnotes%2Fcompiler%2FsimplCore%2FSim
|  plify.hs.html%23note-case-to-let-
|  transformation&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C377b6cd1b01
|  0436a17c508d8567ca96f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
|  54441318347955&amp;sdata=vyO%2FXLW3q3xh8gev%2BLLGxRxL4glGMVb61OYcGc7%2B
|  tpo%3D&amp;reserved=0
|  
|  The docs for the transformation say that it makes this replacement:
|  
|  case a +# b of r -> …r… into let r = a +# b in …r…
|  
|  But this creates a let binding with an unlifted binder, which the
|  linter
|  does not like:
|  
|  <no location info>: warning:
|      [RHS of ... :: Int#]
|      The type of this binder is unlifted: ...
|      Binder's type: Int#
|  
|  Arguably, this rule might expect the let to be inlined, but we're
|  seeing
|  that the let stands, and the linter complains.
|  
|  My immediate concern is getting around this problem somehow so I can
|  run
|  the linter on later output of the simplifier.  Is there any way to do
|  this?  I.e. don't stop when the linter complains, somehow massage the
|  rules to work better - see below.  Any help would be much appreciated!
|  (I'm using ghc 8.8.3.)
|  
|  More details:
|  
|  The ConCat code has this rule:
|  
|  "rebox2" [~0] (+#) = \ u# v# -> unboxI (addC (boxI u#, boxI v#))
|  
|  It fires like this:
|  
|  Rule fired
|      Rule: rebox_2
|      Module: (ConCat.Rebox)
|      Before: GHC.Prim.+# ValArg 10# ValArg 1#
|      After:  (\ (u#_aM4G :: GHC.Prim.Int#) (v#_aM4H :: GHC.Prim.Int#) ->
|                 ConCat.Rebox.unboxI
|                   (ConCat.AltCat.addC
|                      @ (->)
|                      @ GHC.Types.Int
|                      (ConCat.Category.$fNumCat->a @ GHC.Types.Int
|  GHC.Num.$fNumInt)
|                      (ConCat.Rebox.boxI u#_aM4G, ConCat.Rebox.boxI
|  v#_aM4H)))
|                10# 1#
|      Cont:   Stop[BoringCtxt] GHC.Prim.Int#
|  
|  ... and comes out of the simplifier like this:
|  
|  let {
|    n1_sM4V :: GHC.Prim.Int#
|    [LclId,
|     Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False,
|             WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 110
|  0}]
|    n1_sM4V
|      = case ConCat.AltCat.addC
|               @ (->)
|               @ GHC.Types.Int
|               (ConCat.Category.$fNumCat->a
|                  @ GHC.Types.Int GHC.Num.$fNumInt)
|               (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#)
|        of
|        { GHC.Types.I# i#_aM4S ->
|        i#_aM4S
|        } } in
|  GHC.Types.I#
|    (case ConCat.AltCat.addC
|            @ (->)
|            @ GHC.Types.Int
|            (ConCat.Category.$fNumCat->a @ GHC.Types.Int
|  GHC.Num.$fNumInt)
|            (ConCat.Rebox.boxI 10#, ConCat.Rebox.boxI 1#)
|     of
|     { GHC.Types.I# i#_aM4S ->
|     i#_aM4S
|     }) } in ...
|  
|  Ironically, you can see that the simplifier already *has* inlined, just
|  not elided the (now dead) let binding yet, before the linter gets to
|  it.
|  
|  I've also attached a shorter source file with the relevant rules that
|  triggers the linter, albeit with a different message.
|  
|  Richard Eisenberg, Gabor Greif, and Conal helped me get to this point.
|  Many thanks to them!
|  
|  --
|  Regards,
|  Mike

From qdunkan at gmail.com  Mon Sep 14 00:38:15 2020
From: qdunkan at gmail.com (Evan Laforge)
Date: Sun, 13 Sep 2020 17:38:15 -0700
Subject: WebUI for GHC/Haskell tooling (eventlog)
In-Reply-To: <CANjChEqhfmbN_BU1cm_ja0fWMu1Sgp0JsrAVdvXucx_W3e6gwA@mail.gmail.com>
References: <CANjChEqhfmbN_BU1cm_ja0fWMu1Sgp0JsrAVdvXucx_W3e6gwA@mail.gmail.com>
Message-ID: <CACbaDy7rqD46dXjfaxPriSeY94h8dJEVrjiMhjLNjNhxVziBKw@mail.gmail.com>

Hi, I read your post back when you posted it and meant to respond, but got
distracted!  Anyway, I think the profiling tools in ghc could definitely use
some attention, so I'm glad you're looking into this!

The below is going to seem like a rant, and maybe it is in some parts, but
I mean it to be a constructive attempt to chart the gaps in documentation or
tools.  It has been observed many times that the haskell performance story is
scattered about, and many people have suggested some kind of consolidation,
which of course is always The Problem, especially for open source.  So here
I am observing that again, but there does seem to be promising movement
as people get more interested in performance, and your efforts are
encouraging.

### documentation

It would be really nice to get more complete and detailed documentation of
what the options are, and gather it into one place.  This is a disorganized
list of my own experiences:

The time units in all the profiles seem mysterious.  There's a "total time"
in the .prof file.  There's a time axis on the heap profile.  There are times
in the GC summary (INIT, MUT, ..., Total).  None of these times seem to
correspond with each other.  What do they mean?  Similarly, the "total bytes"
in the prof file doesn't seem to correspond to anything in the GC summary.
Long ago (maybe around 10 years ago) I think I intuited that the heap profile
time is CPU time, which is what foiled my attempts to separate program phases
with sleeps so I could see them.  I resorted to live profiling with ekg, and
more recently I have tried to use the eventlog and custom events for that
(eventlog2html does draw the event positions, but the feature to show the
event text didn't work for me).  Anyway, there are many tools and techniques,
but I haven't seen documentation tieing them together, along with advice and
experience reports and all that good stuff.

So I improvise.  Here is my latest attempt, for ad-hoc profile exploration:
https://github.com/elaforge/karya/blob/work/tools/run_profile.py
It fiddles with all the flags I can never remember, collects and archives the
results in a dated directory, runs all the various tools I can never remember
(ghc-prof-flamegraph has been ostensibly the most useful, but see below about
SCCs), and tries to extract a summary of the somewhat more stable numbers
(GC stats and top profile cost centers) so I can diff them.

Then there is a completely different attempt to get historical performance by
running on known inputs, with the optimized non-profiling binary, extract the
actual runtimes of various phases, and put them in a database to query later:
https://github.com/elaforge/karya/tree/work/tools/timing  This is because
I don't trust profile-built binaries to be ground truth, even if it's just
-prof and the eventlog runtime, no SCCs.

I did some work to convert event logs to the chrome tracing format:
https://github.com/elaforge/karya/blob/work/App/ConvertEventLog.hs In the end,
I didn't use the graphical tracing, but just did ad-hoc analysis of the
timestamps to see who was most expensive.  The event format is another place
where documentation would be nice, as you can see from the file, I just copy
pasted the definition out of ghc and guessed what the types mean from their
names.  This was in the ghc 8.0 era I think, and I recall that the eventlog
acquired heap data after that.  I did get it working as a replacement for
ThreadScope, and I think in general reusing a general framework that other
people maintain will work better than a custom GTK app when the maintainer
count is in the 0 to 1 range, though I recall chrome consumes JSON and trying
to get that much data through JSON hit a wall eventually.  I guess JSON
should be theoretically capable of arbitrary sizes, so presumably it was that
chrome is not optimized for large data... which might undercut the idea that
it's better to use someone else's tool.

Despite all of this, over the last 10 or so years, I have never managed to get
predictable or consistent numbers, e.g. after a ghc version change they get
dramatically worse in theory, but seem to be about the same wall clock time.
Or they steadily creep down or up over long periods where no changes should
have affected them, or there is no apparent improvement after a change that
eliminated a top SCC entry, etc. etc.  And this is without the confounding
factor of changing hardware, since I do have hardware that's unchanged from 10
years back (I'm lazy about upgrading, ok?)... though of course hardware is
confounding in general, and I haven't seen any techniques for how to control
for that.  Even on the same hardware, CPUs and OSes are quite
non-deterministic, but the best approach I've seen there is criterion-style
analysis for short benchmarks, and for long ones I just run them multiple
times and hope they are below the noise floor.

Anyway, I know all this stuff goes beyond just haskell and ghc, and is part of
the general theme that profiling and benchmarking is hard and no one
really seems to know how to do it satisfactorily.  For example, here is a fun
blog post on how even the mainstream VM world has apparently failed to get
useful benchmarks on JIT:
https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_our_vms_part_1.html
which reminds me of how it seems only recently did people realize, in the
context of mtl vs. various free monads, that the key to mtl performance is
monomorphic inlining.  But despite all that, surely we can do better than just
banging around blindly alone, as I've done.  I think other people have had
better success than I have, and I would love to learn from their examples.

There is also a whole battery of language-agnostic low level tools from Intel
and whatnot that the HPC or video games people use, and while ghc haskell
can be a bit far from that, it doesn't mean they're useless... I've seen
references to them used even for python.  After just a little bit of time
lurking on a rust-oriented chat, it seems like they think about performance
(both throughput and latency) in a more rigorous and systematic way, and more
connected to the broader performance-oriented community.  Maybe similar to the
way haskell has traditionally been more rigorous and systematic about
abstractions and correctness, and more connected to the broader math-oriented
community.

The whole thing about SCCs could also use some documentation and advice.  Due
to some of the experiences above, I don't trust -fprof-auto-* flags,
and I have seen some blog posts supporting that.  The basic problem as
I understand it is that SCCs prevent inlining, and inlining is the way
important optimizations happen.  But there they are, very tempting, and there
is even a new one, -fprof-auto-exported, that seems to want to solve the
inlining problem, but it can't really, because what you really want is SCCs on
non-inlined functions, and I gather that's awkward given the order of the ghc
pipeline.  But cabal compiles all external libraries with "exported-functions"
by default (which you have to look up to figure out that it's
-fprof-auto-exported... can we pick consistent names?), with the result
that (I think!) the SCCs stymie the inlining and specialization of (>>=),
which, as has been documented (by which I mean the usual blog and reddit
posts) to completely alter the performance of mtl style monadic code.  So the
first step is to set 'profiling-detail: none' and recompile the whole world,
which used to be a lot more hassle, but I think cabal V2 has improved matters.
But, all that said, I also understand why the auto-scc stuff is so tempting,
just to give an overview before you try to zoom in manually with SCCs, because
there are zillions of functions to annotate.  What approach to use when?  Has
anyone come up with satisfying guidance?

Then there are fascinating experiments like
https://github.com/Petrosz007/haskell-profile-highlight , which is something
I dreamed about from the beginning, except that it relies on pervasive SCCs
so... is it ok to build on that foundation?

Oh and speaking of SCCs, there's a bug (?) where the entries is 0 sometimes.
Every once in a while someone posts somewhere asking about that and no one
seems to know.

Every time I do biographical profiling I have to remind myself what exactly
are LAG, DRAG, INHERENT_USE, VOID.  So I search my gmail box, because
the only documentation I have is a very helpful response Simon
Marlow sent to me asking those very questions 10 years back, and the original
1996 biographical profiling paper
(http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.1219) that he
mentions.  To this day, if I search the mailing list archives for INHERENT_USE
that is the only message that comes up!  The paper is still
relevant, because it seems the implementation hasn't changed much since 1996
either, but dummies like me need lots of examples and case studies for things
to stick.

Also INHERENT_USE seems to date from pre-bytestring days when no one had
significant data in ByteArrays so it was ok to just handwave it away.  That
isn't the case anymore, and it means that often most data is not tracked.
There is a ghc ticket to improve the situation:
https://gitlab.haskell.org/ghc/ghc/-/issues/7275 There has been consistent
interest over its 7 years, looks like it just lacks a volunteer!

Then there is folk knowledge about what ARR_WORDS is.  I recently stumbled
across a very helpful post by Ben Gamari:
https://bgamari.github.io/posts/2016-03-30-what-is-this-array.html  There are
a bunch of other internal closure types though, which as far as I know require
knowing ghc internals to understand.

And then there is a whole zoo of ad-hoc techniques scattered across blog posts
over the last 10 years or so: Neil Mitchell's stack-limiting leak-finder,
Simon Marlow's weak pointer leak finder, and an absolutely heroic post about
using gdb to directly inspect ghc data structures and find leaks:
https://lukelau.me/haskell/posts/leak/
Here's a recent one about memory fragmentation, that might also be the answer
to my bytes discrepancy questions above:
https://www.well-typed.com/blog/2020/08/memory-fragmentation/

And of course various ghc pragmas which are actually pretty well documented,
but the advice on how to use them is still scattered around in blog posts:
INLINE vs. INLINABLE vs. SPECIALIZE, rewrite rules, etc.

And then there's folk knowledge about libraries and data structures, e.g.
Writer being inefficient so use strict StateT instead, but someone also put up
writer-cps-mtl, but hey it says it was merged into 'transformers' so maybe
that's all obsolete now?  And Either/ExceptT is also inefficient but in
theory CPS transform fixes that too... but still no except-cps-mtl?  I wrote
my own by hand, which seemed to be what everyone was doing at the time, but as
usual I couldn't demonstrate an actual performance improvement from it.  By
the way, I assume that is the answer to the attoparsec question on
https://www.reddit.com/r/haskell/comments/ir3hmr/compiling_systems_haskell_resourcesexamples/

And the existence of short-text and short-bytestring, and of course the
famousest folk knowledge, which is difference lists, but actually sometimes
they hurt more than help, and no one seems to mention that.  Or the AppendList
(called OrdList in ghc source) which never seemed to gain significant
popularity... including with me, since I couldn't get it to demonstrate
a performance improvement over [] and (++)... but ghc does use it and maybe
you just have to use it right?

There's also some folk wisdom about LLVM-for-your-loops and vectorization...
e.g. I noticed that a foreign call to a C function that does a nested
loop to sum
buffers of floats is an order of magnitude faster than a loop in ST with
unsafeWrite, which is another order of magnitude faster than the high-level
Unboxed.Vector.zipWith stuff, and I assume auto vectorization might be to
blame.  Of course it seems no one knows how to do it without one of flaky
automatic optimization, or grungy explicit intrinsics calls, or an entirely
new DSL or language, though I suppose haskell does have entries such as
'accelerate' and 'repa'.  But anyway, that's getting into low level
performance and numerics, which is a whole specialized field on its
own, and it seems hard to port its solutions into general purpose code.

From simonpj at microsoft.com  Mon Sep 14 10:25:11 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Sep 2020 10:25:11 +0000
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>

I thought I’d sent a message about this DynFlags thing, but I can’t trace it now.   So here’s a resend.

Currently

  *   The DynFlags record includes Hooks
  *   Hooks in contains functions, that mention TcM, DsM etc

This is bad.  We should think of DynFlags as an abstract syntax tree.  That is, the result of parsing the flag strings, yes, but not much more.  So for hooks we should have an algebraic data type representing the hook specification, but it should not be the hook functions themselves.  HsSyn, for example, after parsing, is just a tree with strings in it.  No TyCons, Ids, etc. That comes much later.

So DynFlags should be a collection of algebraic data types, but should not depend on anything else.

I think that may cut a bunch of awkward loops.

Simon

From: Simon Peyton Jones
Sent: 10 September 2020 14:17
To: Sebastian Graf <sgraf1337 at gmail.com>; Sylvain Henry <sylvain at haskus.fr>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: RE: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

And for sure the *parser* should not depend on the *desugarer* and *typechecker*.   (Which it does, as described below.)

S

From: ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Sebastian Graf
Sent: 10 September 2020 14:12
To: Sylvain Henry <sylvain at haskus.fr<mailto:sylvain at haskus.fr>>
Cc: ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

Hey Sylvain,

In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0> I had to fight once more with the transitive dependency set of the parser, the minimality of which is crucial for ghc-lib-parser<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0> and tested by the CountParserDeps test.

I discovered that I need to make (parts of) `DsM` abstract, because it is transitively imported from the Parser for example through Parser.y -> Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
Since you are our mastermind behind the "Tame DynFlags" initiative, I'd like to hear your opinion on where progress can be/is made on that front.

I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0> and https://gitlab.haskell.org/ghc/ghc/-/issues/11301<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0> which ask a related, but different question: They want a DynFlags-free interface, but I even want a DynFlags-free *module*.

Would you say it's reasonable to abstract the definition of `PState` over the `DynFlags` type? I think it's only used for pretty-printing messages, which is one of your specialties (the treatment of DynFlags in there, at least).
Anyway, can you think of or perhaps point me to an existing road map on that issue?

Thank you!
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200914/48923fb5/attachment.html>

From adam at well-typed.com  Mon Sep 14 11:08:29 2020
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 14 Sep 2020 12:08:29 +0100
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>

I'm supportive of the goal, but a complication with removing hooks from
DynFlags is that GHC currently supports "DynFlags plugins" that allow
plugins to install custom hooks
(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins).
I guess this can be worked around, perhaps by passing hooks separately
to DynFlags and providing a separate plugin interface to modify hooks.
But doing so will necessarily break existing plugins.

Adam


On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
> I thought I’d sent a message about this DynFlags thing, but I can’t
> trace it now.   So here’s a resend.
> 
>  
> 
> Currently
> 
>   * The DynFlags record includes Hooks
>   * Hooks in contains functions, that mention TcM, DsM etc
> 
>  
> 
> This is bad.  We should think of DynFlags as an *abstract syntax tree*. 
> That is, the result of parsing the flag strings, yes, but not much
> more.  So for hooks we should have an algebraic data type representing
> the hook /specification/, but it should not be the hook functions
> themselves.  HsSyn, for example, after parsing, is just a tree with
> strings in it.  No TyCons, Ids, etc. That comes much later.
> 
>  
> 
> So DynFlags should be a collection of algebraic data types, but should
> not depend on anything else.
> 
>  
> 
> I think that may cut a bunch of awkward loops.
> 
>  
> 
> Simon
> 
>  
> 
> *From:*Simon Peyton Jones
> *Sent:* 10 September 2020 14:17
> *To:* Sebastian Graf <sgraf1337 at gmail.com>; Sylvain Henry
> <sylvain at haskus.fr>
> *Cc:* ghc-devs <ghc-devs at haskell.org>
> *Subject:* RE: Parser depends on DynFlags, depends on Hooks, depends on
> TcM, DsM, ...
> 
>  
> 
> And for sure the **parser** should not depend on the **desugarer** and
> **typechecker**.   (Which it does, as described below.)
> 
>  
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
> S
> 
>  
> 
> *From:*ghc-devs <ghc-devs-bounces at haskell.org
> <mailto:ghc-devs-bounces at haskell.org>> *On Behalf Of *Sebastian Graf
> *Sent:* 10 September 2020 14:12
> *To:* Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>>
> *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
> *Subject:* Parser depends on DynFlags, depends on Hooks, depends on TcM,
> DsM, ...
> 
>  
> 
> Hey Sylvain,
> 
>  
> 
> In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0>
> I had to fight once more with the transitive dependency set of the
> parser, the minimality of which is crucial for ghc-lib-parser
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0>
> and tested by the CountParserDeps test.
> 
>  
> 
> I discovered that I need to make (parts of) `DsM` abstract, because it
> is transitively imported from the Parser for example through Parser.y ->
> Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
> 
> Since you are our mastermind behind the "Tame DynFlags" initiative, I'd
> like to hear your opinion on where progress can be/is made on that front.
> 
>  
> 
> I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0>
> and https://gitlab.haskell.org/ghc/ghc/-/issues/11301
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0>
> which ask a related, but different question: They want a DynFlags-free
> interface, but I even want a DynFlags-free *module*.
> 
>  
> 
> Would you say it's reasonable to abstract the definition of `PState`
> over the `DynFlags` type? I think it's only used for pretty-printing
> messages, which is one of your specialties (the treatment of DynFlags in
> there, at least).
> 
> Anyway, can you think of or perhaps point me to an existing road map on
> that issue?
> 
>  
> 
> Thank you!
> 
> Sebastian



-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England

From simonpj at microsoft.com  Mon Sep 14 11:45:09 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Sep 2020 11:45:09 +0000
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
Message-ID: <VI1PR83MB042992ED4A2C9000824FF792AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>

|  I guess this can be worked around, perhaps by passing hooks separately
|  to DynFlags and providing a separate plugin interface to modify hooks.
|  But doing so will necessarily break existing plugins.

I'm not sure it will break anything.  It's hard to find just what the API that plugin authors use.. where is it documented?

All I'm arguing is that Hooks (which contains the hook functions themselves) should not be part of DynFlags.  So for example:

dsForeigns :: [LForeignDecl GhcTc]
           -> DsM (ForeignStubs, OrdList Binding)
dsForeigns fos = getHooked dsForeignsHook dsForeigns' >>= ($ fos)

Here
  getHooked :: (Functor f, HasDynFlags f) => (Hooks -> Maybe a) -> a -> f a

Why HasDynFlags?  Yes, DsM might need a Hooks field, but that's easy. No need to stuff it in DynFlags!

Simon

|  -----Original Message-----
|  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Adam Gundry
|  Sent: 14 September 2020 12:08
|  To: ghc-devs at haskell.org
|  Subject: Re: Parser depends on DynFlags, depends on Hooks, depends on
|  TcM, DsM, ...
|  
|  I'm supportive of the goal, but a complication with removing hooks from
|  DynFlags is that GHC currently supports "DynFlags plugins" that allow
|  plugins to install custom hooks
|  (https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownlo
|  ads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending
|  _ghc.html%23dynflags-
|  plugins&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f5
|  4808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735678554
|  4069988&amp;sdata=d8wJidQddoONBhJXnv6iI1%2FD4gVDq%2FvC7cgSxJoBOFQ%3D&am
|  p;reserved=0).
|  I guess this can be worked around, perhaps by passing hooks separately
|  to DynFlags and providing a separate plugin interface to modify hooks.
|  But doing so will necessarily break existing plugins.
|  
|  Adam
|  
|  
|  On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
|  > I thought I’d sent a message about this DynFlags thing, but I can’t
|  > trace it now.   So here’s a resend.
|  >
|  >
|  >
|  > Currently
|  >
|  >   * The DynFlags record includes Hooks
|  >   * Hooks in contains functions, that mention TcM, DsM etc
|  >
|  >
|  >
|  > This is bad.  We should think of DynFlags as an *abstract syntax
|  tree*.
|  > That is, the result of parsing the flag strings, yes, but not much
|  > more.  So for hooks we should have an algebraic data type
|  representing
|  > the hook /specification/, but it should not be the hook functions
|  > themselves.  HsSyn, for example, after parsing, is just a tree with
|  > strings in it.  No TyCons, Ids, etc. That comes much later.
|  >
|  >
|  >
|  > So DynFlags should be a collection of algebraic data types, but
|  should
|  > not depend on anything else.
|  >
|  >
|  >
|  > I think that may cut a bunch of awkward loops.
|  >
|  >
|  >
|  > Simon
|  >
|  >
|  >
|  > *From:*Simon Peyton Jones
|  > *Sent:* 10 September 2020 14:17
|  > *To:* Sebastian Graf <sgraf1337 at gmail.com>; Sylvain Henry
|  > <sylvain at haskus.fr>
|  > *Cc:* ghc-devs <ghc-devs at haskell.org>
|  > *Subject:* RE: Parser depends on DynFlags, depends on Hooks, depends
|  on
|  > TcM, DsM, ...
|  >
|  >
|  >
|  > And for sure the **parser** should not depend on the **desugarer**
|  and
|  > **typechecker**.   (Which it does, as described below.)
|  >
|  >
|  >
|  https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_
|  ghc.html%23dynflags-
|  plugins&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f5
|  4808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735678554
|  4069988&amp;sdata=d8wJidQddoONBhJXnv6iI1%2FD4gVDq%2FvC7cgSxJoBOFQ%3D&am
|  p;reserved=0
|  > S
|  >
|  >
|  >
|  > *From:*ghc-devs <ghc-devs-bounces at haskell.org
|  > <mailto:ghc-devs-bounces at haskell.org>> *On Behalf Of *Sebastian Graf
|  > *Sent:* 10 September 2020 14:12
|  > *To:* Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>>
|  > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
|  > *Subject:* Parser depends on DynFlags, depends on Hooks, depends on
|  TcM,
|  > DsM, ...
|  >
|  >
|  >
|  > Hey Sylvain,
|  >
|  >
|  >
|  > In
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  b.haskell.org%2Fghc%2Fghc%2F-
|  %2Fmerge_requests%2F3971&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0
|  e358ff421a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637356785544069988&amp;sdata=OV1X6btPhnB7UPxOKvCRzUOZVlH7r5ZpR33d
|  6vil3fI%3D&amp;reserved=0
|  >
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.haskell.org%2Fghc%2Fghc%2F-
|  %2Fmerge_requests%2F3971&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0
|  e358ff421a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637356785544069988&amp;sdata=OV1X6btPhnB7UPxOKvCRzUOZVlH7r5ZpR33d
|  6vil3fI%3D&amp;reserved=0>
|  > I had to fight once more with the transitive dependency set of the
|  > parser, the minimality of which is crucial for ghc-lib-parser
|  >
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhack
|  age.haskell.org%2Fpackage%2Fghc-lib-
|  parser&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f54
|  808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356785544
|  079987&amp;sdata=bHnY1UZgFauLsB0dISUXZavGholi6UWzA7nSuByMCns%3D&amp;res
|  erved=0>
|  > and tested by the CountParserDeps test.
|  >
|  >
|  >
|  > I discovered that I need to make (parts of) `DsM` abstract, because
|  it
|  > is transitively imported from the Parser for example through Parser.y
|  ->
|  > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
|  >
|  > Since you are our mastermind behind the "Tame DynFlags" initiative,
|  I'd
|  > like to hear your opinion on where progress can be/is made on that
|  front.
|  >
|  >
|  >
|  > I see there is
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  b.haskell.org%2Fghc%2Fghc%2F-
|  %2Fissues%2F10961&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  37356785544079987&amp;sdata=pghmuc9gmaHinB8cLZHx2PqBqDwNkBJBSFZsYlCdwL8
|  %3D&amp;reserved=0
|  >
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.haskell.org%2Fghc%2Fghc%2F-
|  %2Fissues%2F10961&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  37356785544079987&amp;sdata=pghmuc9gmaHinB8cLZHx2PqBqDwNkBJBSFZsYlCdwL8
|  %3D&amp;reserved=0>
|  > and
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  b.haskell.org%2Fghc%2Fghc%2F-
|  %2Fissues%2F11301&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  37356785544079987&amp;sdata=tiE1uhe%2BganXJKPbtadDGUCnSi%2F0OMT6WopEZ9s
|  MJJY%3D&amp;reserved=0
|  >
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  ab.haskell.org%2Fghc%2Fghc%2F-
|  %2Fissues%2F11301&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  37356785544079987&amp;sdata=tiE1uhe%2BganXJKPbtadDGUCnSi%2F0OMT6WopEZ9s
|  MJJY%3D&amp;reserved=0>
|  > which ask a related, but different question: They want a DynFlags-
|  free
|  > interface, but I even want a DynFlags-free *module*.
|  >
|  >
|  >
|  > Would you say it's reasonable to abstract the definition of `PState`
|  > over the `DynFlags` type? I think it's only used for pretty-printing
|  > messages, which is one of your specialties (the treatment of DynFlags
|  in
|  > there, at least).
|  >
|  > Anyway, can you think of or perhaps point me to an existing road map
|  on
|  > that issue?
|  >
|  >
|  >
|  > Thank you!
|  >
|  > Sebastian
|  
|  
|  
|  --
|  Adam Gundry, Haskell Consultant
|  Well-Typed LLP,
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w
|  ell-
|  typed.com%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64
|  763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356
|  785544079987&amp;sdata=D9by4KOFhHjYXnRT6okDDCDH6mLKXkZ%2BL%2BvrC4tLCfQ%
|  3D&amp;reserved=0
|  
|  Registered in England & Wales, OC335890
|  118 Wymering Mansions, Wymering Road, London W9 2NF, England
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  devs&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f5480
|  8d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735678554407
|  9987&amp;sdata=3b%2FfWhaolo%2Fsl2m3SFs3lwM7Nfbihf4v6y6gfZ5Qteo%3D&amp;r
|  eserved=0

From moritz.angermann at gmail.com  Mon Sep 14 12:02:47 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 14 Sep 2020 20:02:47 +0800
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
Message-ID: <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>

I believe this to already be broken in HEAD. DynFlags already got quite an
overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
offer alternative stable interfaces. Though to be honest, I believe our
Plugin story is rather poor so far.

Do you happen to know of DynFlagPlugins, Adam?

Cheers,
 Moritz

On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <adam at well-typed.com> wrote:

> I'm supportive of the goal, but a complication with removing hooks from
> DynFlags is that GHC currently supports "DynFlags plugins" that allow
> plugins to install custom hooks
> (
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
> ).
> I guess this can be worked around, perhaps by passing hooks separately
> to DynFlags and providing a separate plugin interface to modify hooks.
> But doing so will necessarily break existing plugins.
>
> Adam
>
>
> On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
> > I thought I’d sent a message about this DynFlags thing, but I can’t
> > trace it now.   So here’s a resend.
> >
> >
> >
> > Currently
> >
> >   * The DynFlags record includes Hooks
> >   * Hooks in contains functions, that mention TcM, DsM etc
> >
> >
> >
> > This is bad.  We should think of DynFlags as an *abstract syntax tree*.
> > That is, the result of parsing the flag strings, yes, but not much
> > more.  So for hooks we should have an algebraic data type representing
> > the hook /specification/, but it should not be the hook functions
> > themselves.  HsSyn, for example, after parsing, is just a tree with
> > strings in it.  No TyCons, Ids, etc. That comes much later.
> >
> >
> >
> > So DynFlags should be a collection of algebraic data types, but should
> > not depend on anything else.
> >
> >
> >
> > I think that may cut a bunch of awkward loops.
> >
> >
> >
> > Simon
> >
> >
> >
> > *From:*Simon Peyton Jones
> > *Sent:* 10 September 2020 14:17
> > *To:* Sebastian Graf <sgraf1337 at gmail.com>; Sylvain Henry
> > <sylvain at haskus.fr>
> > *Cc:* ghc-devs <ghc-devs at haskell.org>
> > *Subject:* RE: Parser depends on DynFlags, depends on Hooks, depends on
> > TcM, DsM, ...
> >
> >
> >
> > And for sure the **parser** should not depend on the **desugarer** and
> > **typechecker**.   (Which it does, as described below.)
> >
> >
> >
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
> > S
> >
> >
> >
> > *From:*ghc-devs <ghc-devs-bounces at haskell.org
> > <mailto:ghc-devs-bounces at haskell.org>> *On Behalf Of *Sebastian Graf
> > *Sent:* 10 September 2020 14:12
> > *To:* Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>>
> > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
> > *Subject:* Parser depends on DynFlags, depends on Hooks, depends on TcM,
> > DsM, ...
> >
> >
> >
> > Hey Sylvain,
> >
> >
> >
> > In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0
> >
> > I had to fight once more with the transitive dependency set of the
> > parser, the minimality of which is crucial for ghc-lib-parser
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0
> >
> > and tested by the CountParserDeps test.
> >
> >
> >
> > I discovered that I need to make (parts of) `DsM` abstract, because it
> > is transitively imported from the Parser for example through Parser.y ->
> > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
> >
> > Since you are our mastermind behind the "Tame DynFlags" initiative, I'd
> > like to hear your opinion on where progress can be/is made on that front.
> >
> >
> >
> > I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0
> >
> > and https://gitlab.haskell.org/ghc/ghc/-/issues/11301
> > <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0
> >
> > which ask a related, but different question: They want a DynFlags-free
> > interface, but I even want a DynFlags-free *module*.
> >
> >
> >
> > Would you say it's reasonable to abstract the definition of `PState`
> > over the `DynFlags` type? I think it's only used for pretty-printing
> > messages, which is one of your specialties (the treatment of DynFlags in
> > there, at least).
> >
> > Anyway, can you think of or perhaps point me to an existing road map on
> > that issue?
> >
> >
> >
> > Thank you!
> >
> > Sebastian
>
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 118 Wymering Mansions, Wymering Road, London W9 2NF, England
> _______________________________________________
> 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/20200914/34e375ce/attachment.html>

From adam at well-typed.com  Mon Sep 14 12:12:00 2020
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 14 Sep 2020 13:12:00 +0100
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <VI1PR83MB042992ED4A2C9000824FF792AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <VI1PR83MB042992ED4A2C9000824FF792AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <1d611c13-5cca-62fa-3dc5-d026ef4d5208@well-typed.com>

On 14/09/2020 12:45, Simon Peyton Jones via ghc-devs wrote:
> |  I guess this can be worked around, perhaps by passing hooks separately
> |  to DynFlags and providing a separate plugin interface to modify hooks.
> |  But doing so will necessarily break existing plugins.
> 
> I'm not sure it will break anything.  It's hard to find just what the API that plugin authors use.. where is it documented?

The link to the GHC user's guide [1] I gave includes an example of a
DynFlags plugin overriding a hook. This was the key reason for
introducing DynFlags plugins originally [2] and is definitely used in
the wild [3]. TBH I'm not sure DynFlags plugins are yet used for
anything *other* than overriding hooks.


> All I'm arguing is that Hooks (which contains the hook functions themselves) should not be part of DynFlags.  So for example:
> 
> dsForeigns :: [LForeignDecl GhcTc]
>            -> DsM (ForeignStubs, OrdList Binding)
> dsForeigns fos = getHooked dsForeignsHook dsForeigns' >>= ($ fos)
> 
> Here
>   getHooked :: (Functor f, HasDynFlags f) => (Hooks -> Maybe a) -> a -> f a
> 
> Why HasDynFlags?  Yes, DsM might need a Hooks field, but that's easy. No need to stuff it in DynFlags!

Right, I agree completely. I don't know about the initial implementation
of hooks, but I suspect DynFlags was picked as a convenient way to pass
them throughout the compiler, at the cost of introducing more cycles.

I just suggest that either the Plugin type gets extended with a new
hooksPlugin field of type

    [CommandLineOption] -> Hooks -> IO Hooks

or the type of the existing dynflagsPlugin field is changed to something
like

    [CommandLineOption] -> (DynFlags, Hooks) -> IO (DynFlags, Hooks)

so that plugins can still set up hooks. Though perhaps there is an even
better story lurking here about combining Hooks and Plugins rather than
having a somewhat artificial separation between them...

Adam


[1]
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
[2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1580
[3] https://gitlab.haskell.org/alp/ghc-external-splices-plugin


> Simon
> 
> |  -----Original Message-----
> |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Adam Gundry
> |  Sent: 14 September 2020 12:08
> |  To: ghc-devs at haskell.org
> |  Subject: Re: Parser depends on DynFlags, depends on Hooks, depends on
> |  TcM, DsM, ...
> |  
> |  I'm supportive of the goal, but a complication with removing hooks from
> |  DynFlags is that GHC currently supports "DynFlags plugins" that allow
> |  plugins to install custom hooks
> |  (https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownlo
> |  ads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending
> |  _ghc.html%23dynflags-
> |  plugins&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f5
> |  4808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735678554
> |  4069988&amp;sdata=d8wJidQddoONBhJXnv6iI1%2FD4gVDq%2FvC7cgSxJoBOFQ%3D&am
> |  p;reserved=0).
> |  I guess this can be worked around, perhaps by passing hooks separately
> |  to DynFlags and providing a separate plugin interface to modify hooks.
> |  But doing so will necessarily break existing plugins.
> |  
> |  Adam
> |  
> |  
> |  On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
> |  > I thought I’d sent a message about this DynFlags thing, but I can’t
> |  > trace it now.   So here’s a resend.
> |  >
> |  >
> |  >
> |  > Currently
> |  >
> |  >   * The DynFlags record includes Hooks
> |  >   * Hooks in contains functions, that mention TcM, DsM etc
> |  >
> |  >
> |  >
> |  > This is bad.  We should think of DynFlags as an *abstract syntax
> |  tree*.
> |  > That is, the result of parsing the flag strings, yes, but not much
> |  > more.  So for hooks we should have an algebraic data type
> |  representing
> |  > the hook /specification/, but it should not be the hook functions
> |  > themselves.  HsSyn, for example, after parsing, is just a tree with
> |  > strings in it.  No TyCons, Ids, etc. That comes much later.
> |  >
> |  >
> |  >
> |  > So DynFlags should be a collection of algebraic data types, but
> |  should
> |  > not depend on anything else.
> |  >
> |  >
> |  >
> |  > I think that may cut a bunch of awkward loops.
> |  >
> |  >
> |  >
> |  > Simon
> |  >
> |  >
> |  >
> |  > *From:*Simon Peyton Jones
> |  > *Sent:* 10 September 2020 14:17
> |  > *To:* Sebastian Graf <sgraf1337 at gmail.com>; Sylvain Henry
> |  > <sylvain at haskus.fr>
> |  > *Cc:* ghc-devs <ghc-devs at haskell.org>
> |  > *Subject:* RE: Parser depends on DynFlags, depends on Hooks, depends
> |  on
> |  > TcM, DsM, ...
> |  >
> |  >
> |  >
> |  > And for sure the **parser** should not depend on the **desugarer**
> |  and
> |  > **typechecker**.   (Which it does, as described below.)
> |  >
> |  >
> |  >
> |  https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
> |  ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_
> |  ghc.html%23dynflags-
> |  plugins&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f5
> |  4808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735678554
> |  4069988&amp;sdata=d8wJidQddoONBhJXnv6iI1%2FD4gVDq%2FvC7cgSxJoBOFQ%3D&am
> |  p;reserved=0
> |  > S
> |  >
> |  >
> |  >
> |  > *From:*ghc-devs <ghc-devs-bounces at haskell.org
> |  > <mailto:ghc-devs-bounces at haskell.org>> *On Behalf Of *Sebastian Graf
> |  > *Sent:* 10 September 2020 14:12
> |  > *To:* Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>>
> |  > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
> |  > *Subject:* Parser depends on DynFlags, depends on Hooks, depends on
> |  TcM,
> |  > DsM, ...
> |  >
> |  >
> |  >
> |  > Hey Sylvain,
> |  >
> |  >
> |  >
> |  > In
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> |  b.haskell.org%2Fghc%2Fghc%2F-
> |  %2Fmerge_requests%2F3971&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0
> |  e358ff421a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C0%7C637356785544069988&amp;sdata=OV1X6btPhnB7UPxOKvCRzUOZVlH7r5ZpR33d
> |  6vil3fI%3D&amp;reserved=0
> |  >
> |  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  ab.haskell.org%2Fghc%2Fghc%2F-
> |  %2Fmerge_requests%2F3971&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0
> |  e358ff421a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> |  7C0%7C637356785544069988&amp;sdata=OV1X6btPhnB7UPxOKvCRzUOZVlH7r5ZpR33d
> |  6vil3fI%3D&amp;reserved=0>
> |  > I had to fight once more with the transitive dependency set of the
> |  > parser, the minimality of which is crucial for ghc-lib-parser
> |  >
> |  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhack
> |  age.haskell.org%2Fpackage%2Fghc-lib-
> |  parser&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f54
> |  808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356785544
> |  079987&amp;sdata=bHnY1UZgFauLsB0dISUXZavGholi6UWzA7nSuByMCns%3D&amp;res
> |  erved=0>
> |  > and tested by the CountParserDeps test.
> |  >
> |  >
> |  >
> |  > I discovered that I need to make (parts of) `DsM` abstract, because
> |  it
> |  > is transitively imported from the Parser for example through Parser.y
> |  ->
> |  > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
> |  >
> |  > Since you are our mastermind behind the "Tame DynFlags" initiative,
> |  I'd
> |  > like to hear your opinion on where progress can be/is made on that
> |  front.
> |  >
> |  >
> |  >
> |  > I see there is
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> |  b.haskell.org%2Fghc%2Fghc%2F-
> |  %2Fissues%2F10961&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
> |  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> |  37356785544079987&amp;sdata=pghmuc9gmaHinB8cLZHx2PqBqDwNkBJBSFZsYlCdwL8
> |  %3D&amp;reserved=0
> |  >
> |  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  ab.haskell.org%2Fghc%2Fghc%2F-
> |  %2Fissues%2F10961&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
> |  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> |  37356785544079987&amp;sdata=pghmuc9gmaHinB8cLZHx2PqBqDwNkBJBSFZsYlCdwL8
> |  %3D&amp;reserved=0>
> |  > and
> |  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
> |  b.haskell.org%2Fghc%2Fghc%2F-
> |  %2Fissues%2F11301&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
> |  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> |  37356785544079987&amp;sdata=tiE1uhe%2BganXJKPbtadDGUCnSi%2F0OMT6WopEZ9s
> |  MJJY%3D&amp;reserved=0
> |  >
> |  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> |  ab.haskell.org%2Fghc%2Fghc%2F-
> |  %2Fissues%2F11301&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
> |  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
> |  37356785544079987&amp;sdata=tiE1uhe%2BganXJKPbtadDGUCnSi%2F0OMT6WopEZ9s
> |  MJJY%3D&amp;reserved=0>
> |  > which ask a related, but different question: They want a DynFlags-
> |  free
> |  > interface, but I even want a DynFlags-free *module*.
> |  >
> |  >
> |  >
> |  > Would you say it's reasonable to abstract the definition of `PState`
> |  > over the `DynFlags` type? I think it's only used for pretty-printing
> |  > messages, which is one of your specialties (the treatment of DynFlags
> |  in
> |  > there, at least).
> |  >
> |  > Anyway, can you think of or perhaps point me to an existing road map
> |  on
> |  > that issue?
> |  >
> |  >
> |  >
> |  > Thank you!
> |  >
> |  > Sebastian


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England

From simonpj at microsoft.com  Mon Sep 14 14:31:23 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 14 Sep 2020 14:31:23 +0000
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <1d611c13-5cca-62fa-3dc5-d026ef4d5208@well-typed.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <VI1PR83MB042992ED4A2C9000824FF792AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <1d611c13-5cca-62fa-3dc5-d026ef4d5208@well-typed.com>
Message-ID: <VI1PR83MB0429D36C7301F4857FE81FF2AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>


| This was the key reason for
|  introducing DynFlags plugins originally [2] 

But [2] says: 

"We do so with a new field in the Plugin data type, which lets plugin authors
supply a Hooks -> Hooks function that then gets applied to the hooks already
present in the DynFlags. If several plugins override the hooks, we compose
all the corresponding Hooks -> Hooks functions."

Note "already present in DynFlags".  If we take it out of DynFlags (my goal in this thread), and put it in (say) ModGuts instead, the API will stay the same, no?

Simon

|  -----Original Message-----
|  From: Adam Gundry <adam at well-typed.com>
|  Sent: 14 September 2020 13:12
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-devs at haskell.org
|  Subject: Re: Parser depends on DynFlags, depends on Hooks, depends on
|  TcM, DsM, ...
|  
|  On 14/09/2020 12:45, Simon Peyton Jones via ghc-devs wrote:
|  > |  I guess this can be worked around, perhaps by passing hooks
|  separately
|  > |  to DynFlags and providing a separate plugin interface to modify
|  hooks.
|  > |  But doing so will necessarily break existing plugins.
|  >
|  > I'm not sure it will break anything.  It's hard to find just what the
|  API that plugin authors use.. where is it documented?
|  
|  The link to the GHC user's guide [1] I gave includes an example of a
|  DynFlags plugin overriding a hook. This was the key reason for
|  introducing DynFlags plugins originally [2] and is definitely used in
|  the wild [3]. TBH I'm not sure DynFlags plugins are yet used for
|  anything *other* than overriding hooks.
|  
|  
|  > All I'm arguing is that Hooks (which contains the hook functions
|  themselves) should not be part of DynFlags.  So for example:
|  >
|  > dsForeigns :: [LForeignDecl GhcTc]
|  >            -> DsM (ForeignStubs, OrdList Binding)
|  > dsForeigns fos = getHooked dsForeignsHook dsForeigns' >>= ($ fos)
|  >
|  > Here
|  >   getHooked :: (Functor f, HasDynFlags f) => (Hooks -> Maybe a) -> a
|  -> f a
|  >
|  > Why HasDynFlags?  Yes, DsM might need a Hooks field, but that's easy.
|  No need to stuff it in DynFlags!
|  
|  Right, I agree completely. I don't know about the initial
|  implementation
|  of hooks, but I suspect DynFlags was picked as a convenient way to pass
|  them throughout the compiler, at the cost of introducing more cycles.
|  
|  I just suggest that either the Plugin type gets extended with a new
|  hooksPlugin field of type
|  
|      [CommandLineOption] -> Hooks -> IO Hooks
|  
|  or the type of the existing dynflagsPlugin field is changed to
|  something
|  like
|  
|      [CommandLineOption] -> (DynFlags, Hooks) -> IO (DynFlags, Hooks)
|  
|  so that plugins can still set up hooks. Though perhaps there is an even
|  better story lurking here about combining Hooks and Plugins rather than
|  having a somewhat artificial separation between them...
|  
|  Adam
|  
|  
|  [1]
|  https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_
|  ghc.html%23dynflags-
|  plugins&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cbf260389ea3f4e4259
|  f608d858a765a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735682328
|  4144388&amp;sdata=oiE3yFoPgiMbQvxH2sftNdv3Gak7QKK2KQkZFS6D8Jo%3D&amp;re
|  served=0
|  [2]
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  b.haskell.org%2Fghc%2Fghc%2F-
|  %2Fmerge_requests%2F1580&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cb
|  f260389ea3f4e4259f608d858a765a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637356823284144388&amp;sdata=6R6KkZe69PQdYRpJHGBYa6vt%2Ff0z8C142f
|  gWX7iqZdA%3D&amp;reserved=0
|  [3]
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  b.haskell.org%2Falp%2Fghc-external-splices-
|  plugin&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cbf260389ea3f4e4259f
|  608d858a765a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356823284
|  144388&amp;sdata=gamHplH2iLxtQRYPyT3POO%2F0jAPPHRMSIka81ZMCbuQ%3D&amp;r
|  eserved=0
|  
|  
|  > Simon
|  >
|  > |  -----Original Message-----
|  > |  From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Adam
|  Gundry
|  > |  Sent: 14 September 2020 12:08
|  > |  To: ghc-devs at haskell.org
|  > |  Subject: Re: Parser depends on DynFlags, depends on Hooks, depends
|  on
|  > |  TcM, DsM, ...
|  > |
|  > |  I'm supportive of the goal, but a complication with removing hooks
|  from
|  > |  DynFlags is that GHC currently supports "DynFlags plugins" that
|  allow
|  > |  plugins to install custom hooks
|  > |
|  (https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownlo
|  > |
|  ads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending
|  > |  _ghc.html%23dynflags-
|  > |
|  plugins&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f5
|  > |
|  4808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735678554
|  > |
|  4069988&amp;sdata=d8wJidQddoONBhJXnv6iI1%2FD4gVDq%2FvC7cgSxJoBOFQ%3D&am
|  > |  p;reserved=0).
|  > |  I guess this can be worked around, perhaps by passing hooks
|  separately
|  > |  to DynFlags and providing a separate plugin interface to modify
|  hooks.
|  > |  But doing so will necessarily break existing plugins.
|  > |
|  > |  Adam
|  > |
|  > |
|  > |  On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
|  > |  > I thought I’d sent a message about this DynFlags thing, but I
|  can’t
|  > |  > trace it now.   So here’s a resend.
|  > |  >
|  > |  >
|  > |  >
|  > |  > Currently
|  > |  >
|  > |  >   * The DynFlags record includes Hooks
|  > |  >   * Hooks in contains functions, that mention TcM, DsM etc
|  > |  >
|  > |  >
|  > |  >
|  > |  > This is bad.  We should think of DynFlags as an *abstract syntax
|  > |  tree*.
|  > |  > That is, the result of parsing the flag strings, yes, but not
|  much
|  > |  > more.  So for hooks we should have an algebraic data type
|  > |  representing
|  > |  > the hook /specification/, but it should not be the hook
|  functions
|  > |  > themselves.  HsSyn, for example, after parsing, is just a tree
|  with
|  > |  > strings in it.  No TyCons, Ids, etc. That comes much later.
|  > |  >
|  > |  >
|  > |  >
|  > |  > So DynFlags should be a collection of algebraic data types, but
|  > |  should
|  > |  > not depend on anything else.
|  > |  >
|  > |  >
|  > |  >
|  > |  > I think that may cut a bunch of awkward loops.
|  > |  >
|  > |  >
|  > |  >
|  > |  > Simon
|  > |  >
|  > |  >
|  > |  >
|  > |  > *From:*Simon Peyton Jones
|  > |  > *Sent:* 10 September 2020 14:17
|  > |  > *To:* Sebastian Graf <sgraf1337 at gmail.com>; Sylvain Henry
|  > |  > <sylvain at haskus.fr>
|  > |  > *Cc:* ghc-devs <ghc-devs at haskell.org>
|  > |  > *Subject:* RE: Parser depends on DynFlags, depends on Hooks,
|  depends
|  > |  on
|  > |  > TcM, DsM, ...
|  > |  >
|  > |  >
|  > |  >
|  > |  > And for sure the **parser** should not depend on the
|  **desugarer**
|  > |  and
|  > |  > **typechecker**.   (Which it does, as described below.)
|  > |  >
|  > |  >
|  > |  >
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa
|  > |
|  ds.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_
|  > |  ghc.html%23dynflags-
|  > |
|  plugins&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f5
|  > |
|  4808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63735678554
|  > |
|  4069988&amp;sdata=d8wJidQddoONBhJXnv6iI1%2FD4gVDq%2FvC7cgSxJoBOFQ%3D&am
|  > |  p;reserved=0
|  > |  > S
|  > |  >
|  > |  >
|  > |  >
|  > |  > *From:*ghc-devs <ghc-devs-bounces at haskell.org
|  > |  > <mailto:ghc-devs-bounces at haskell.org>> *On Behalf Of *Sebastian
|  Graf
|  > |  > *Sent:* 10 September 2020 14:12
|  > |  > *To:* Sylvain Henry <sylvain at haskus.fr
|  <mailto:sylvain at haskus.fr>>
|  > |  > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-
|  devs at haskell.org>>
|  > |  > *Subject:* Parser depends on DynFlags, depends on Hooks, depends
|  on
|  > |  TcM,
|  > |  > DsM, ...
|  > |  >
|  > |  >
|  > |  >
|  > |  > Hey Sylvain,
|  > |  >
|  > |  >
|  > |  >
|  > |  > In
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  > |  b.haskell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fmerge_requests%2F3971&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0
|  > |
|  e358ff421a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  > |
|  7C0%7C637356785544069988&amp;sdata=OV1X6btPhnB7UPxOKvCRzUOZVlH7r5ZpR33d
|  > |  6vil3fI%3D&amp;reserved=0
|  > |  >
|  > |
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > |  ab.haskell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fmerge_requests%2F3971&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0
|  > |
|  e358ff421a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  > |
|  7C0%7C637356785544069988&amp;sdata=OV1X6btPhnB7UPxOKvCRzUOZVlH7r5ZpR33d
|  > |  6vil3fI%3D&amp;reserved=0>
|  > |  > I had to fight once more with the transitive dependency set of
|  the
|  > |  > parser, the minimality of which is crucial for ghc-lib-parser
|  > |  >
|  > |
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhack
|  > |  age.haskell.org%2Fpackage%2Fghc-lib-
|  > |
|  parser&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff421a64763f54
|  > |
|  808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356785544
|  > |
|  079987&amp;sdata=bHnY1UZgFauLsB0dISUXZavGholi6UWzA7nSuByMCns%3D&amp;res
|  > |  erved=0>
|  > |  > and tested by the CountParserDeps test.
|  > |  >
|  > |  >
|  > |  >
|  > |  > I discovered that I need to make (parts of) `DsM` abstract,
|  because
|  > |  it
|  > |  > is transitively imported from the Parser for example through
|  Parser.y
|  > |  ->
|  > |  > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
|  > |  >
|  > |  > Since you are our mastermind behind the "Tame DynFlags"
|  initiative,
|  > |  I'd
|  > |  > like to hear your opinion on where progress can be/is made on
|  that
|  > |  front.
|  > |  >
|  > |  >
|  > |  >
|  > |  > I see there is
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  > |  b.haskell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fissues%2F10961&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  > |
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  > |
|  37356785544079987&amp;sdata=pghmuc9gmaHinB8cLZHx2PqBqDwNkBJBSFZsYlCdwL8
|  > |  %3D&amp;reserved=0
|  > |  >
|  > |
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > |  ab.haskell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fissues%2F10961&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  > |
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  > |
|  37356785544079987&amp;sdata=pghmuc9gmaHinB8cLZHx2PqBqDwNkBJBSFZsYlCdwL8
|  > |  %3D&amp;reserved=0>
|  > |  > and
|  > |
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitla
|  > |  b.haskell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fissues%2F11301&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  > |
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  > |
|  37356785544079987&amp;sdata=tiE1uhe%2BganXJKPbtadDGUCnSi%2F0OMT6WopEZ9s
|  > |  MJJY%3D&amp;reserved=0
|  > |  >
|  > |
|  <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
|  > |  ab.haskell.org%2Fghc%2Fghc%2F-
|  > |
|  %2Fissues%2F11301&amp;data=02%7C01%7Csimonpj%40microsoft.com%7C0e358ff4
|  > |
|  21a64763f54808d8589e9b50%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6
|  > |
|  37356785544079987&amp;sdata=tiE1uhe%2BganXJKPbtadDGUCnSi%2F0OMT6WopEZ9s
|  > |  MJJY%3D&amp;reserved=0>
|  > |  > which ask a related, but different question: They want a
|  DynFlags-
|  > |  free
|  > |  > interface, but I even want a DynFlags-free *module*.
|  > |  >
|  > |  >
|  > |  >
|  > |  > Would you say it's reasonable to abstract the definition of
|  `PState`
|  > |  > over the `DynFlags` type? I think it's only used for pretty-
|  printing
|  > |  > messages, which is one of your specialties (the treatment of
|  DynFlags
|  > |  in
|  > |  > there, at least).
|  > |  >
|  > |  > Anyway, can you think of or perhaps point me to an existing road
|  map
|  > |  on
|  > |  > that issue?
|  > |  >
|  > |  >
|  > |  >
|  > |  > Thank you!
|  > |  >
|  > |  > Sebastian
|  
|  
|  --
|  Adam Gundry, Haskell Consultant
|  Well-Typed LLP,
|  https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w
|  ell-
|  typed.com%2F&amp;data=02%7C01%7Csimonpj%40microsoft.com%7Cbf260389ea3f4
|  e4259f608d858a765a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637356
|  823284154386&amp;sdata=NG2gXzd3i%2Beu2PABXS0QOIinkAHLynZqJurwOvc9O6A%3D
|  &amp;reserved=0
|  
|  Registered in England & Wales, OC335890
|  118 Wymering Mansions, Wymering Road, London W9 2NF, England

From ben at well-typed.com  Mon Sep 14 19:20:04 2020
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 14 Sep 2020 15:20:04 -0400
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM,
 ...
In-Reply-To: <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
Message-ID: <878sdckvxb.fsf@smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> I believe this to already be broken in HEAD. DynFlags already got quite an
> overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
> offer alternative stable interfaces. Though to be honest, I believe our
> Plugin story is rather poor so far.
>
To fill in a bit of history here, DynFlags plugins were introduced in
!1827, which arose as an alternative to !1580. The latter proposed a
much more specialised interface specifically allowing plugins to
introduce Hooks. Personally, I far prefer the approach taken in !1580. To
quote my comment on !1580:

> I agree that overriding DynFlags is excessive and, moreover, it
> entrenches the structure of DynFlags as a semi-stable interface. In my
> opinion the current state of DynFlags is a very uneasy compromise and
> really should be refactored (at very least split up into smaller
> records). While it's true that the Hsc capability given to parser
> plugins allows DynFlags to be modified, I would consider this to be
> very much a backdoor and not a supported use.
>
> Hooks, on the other hand, are intended to be extension points for the
> compiler. Consequently it is quite natural for them to be set by
> plugins.

In light of how quickly DynFlags is now changing, I somewhat regret not
pushing back more vigorously against the DynFlags-centric approach. I
tend to agree that we should remove the interface and revert to a more
limited interface that simply deals in Hooks.

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/20200914/0e7c2859/attachment.sig>

From alp at well-typed.com  Mon Sep 14 21:20:13 2020
From: alp at well-typed.com (Alp Mestanogullari)
Date: Mon, 14 Sep 2020 23:20:13 +0200
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <878sdckvxb.fsf@smart-cactus.org>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
 <878sdckvxb.fsf@smart-cactus.org>
Message-ID: <c04b75a6-8807-0b71-d977-895dbaddbc0b@well-typed.com>

My original motivation for !1580 and !1827 (the latter of which ended up 
getting merged) would be equally well supported by an interface with 
more limited scope. My only requirement there was to be able to override 
the meta hook. I therefore would not mind going back to the approach I 
initially took, in !1580, which I preferred back then already. As long 
as we leave a way for plugins to override hooks, my use case will not 
suffer.

On 14/09/2020 21:20, Ben Gamari wrote:
> Moritz Angermann <moritz.angermann at gmail.com> writes:
>
>> I believe this to already be broken in HEAD. DynFlags already got quite an
>> overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
>> offer alternative stable interfaces. Though to be honest, I believe our
>> Plugin story is rather poor so far.
>>
> To fill in a bit of history here, DynFlags plugins were introduced in
> !1827, which arose as an alternative to !1580. The latter proposed a
> much more specialised interface specifically allowing plugins to
> introduce Hooks. Personally, I far prefer the approach taken in !1580. To
> quote my comment on !1580:
>
>> I agree that overriding DynFlags is excessive and, moreover, it
>> entrenches the structure of DynFlags as a semi-stable interface. In my
>> opinion the current state of DynFlags is a very uneasy compromise and
>> really should be refactored (at very least split up into smaller
>> records). While it's true that the Hsc capability given to parser
>> plugins allows DynFlags to be modified, I would consider this to be
>> very much a backdoor and not a supported use.
>>
>> Hooks, on the other hand, are intended to be extension points for the
>> compiler. Consequently it is quite natural for them to be set by
>> plugins.
> In light of how quickly DynFlags is now changing, I somewhat regret not
> pushing back more vigorously against the DynFlags-centric approach. I
> tend to agree that we should remove the interface and revert to a more
> limited interface that simply deals in Hooks.
>
> 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/20200914/1a3b379c/attachment.html>

From alfredo.dinapoli at gmail.com  Tue Sep 15 07:26:33 2020
From: alfredo.dinapoli at gmail.com (Alfredo Di Napoli)
Date: Tue, 15 Sep 2020 09:26:33 +0200
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <c04b75a6-8807-0b71-d977-895dbaddbc0b@well-typed.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
 <878sdckvxb.fsf@smart-cactus.org>
 <c04b75a6-8807-0b71-d977-895dbaddbc0b@well-typed.com>
Message-ID: <CAFqA6+Ux37m5fg8jpd-kD2c2APThgch_T-w1Kx58TpSztt1vgw@mail.gmail.com>

> Do you happen to know of DynFlagPlugins, Adam?

Alas the newly release LiquidHaskell plugin relies on the `dynflagsPlugin`
action, so it would be nice if this was not removed:

https://github.com/ucsd-progsys/liquidhaskell/blob/develop/src/Language/Haskell/Liquid/GHC/Plugin.hs#L146

Ignoring the other options, we rely on `Opt_KeepRawTokenStreams` which is
*key* for the correct behaviour of the plugin. If we were not intercepting
the `DynFlags` at this stage, the lexer would drop any block comments from
the parsed sources and we wouldn't have the chance of parsing the LH
annotations contained within.

Now, truth to be told, due to the fact we ended up re-parsing each module
anyway (for unfortunate reasons) we *could* survive without it by tweaking
the `DynFlags` inside the `ModSummary` before we call `parseModule`, but in
an ideal world we wouldn't need this, and we would be using directly the
parsed source that the `parsedResultAction` would give us. Without the
`dynflagsPlugin` I don't think we would be able to do that anymore.




On Mon, 14 Sep 2020 at 23:20, Alp Mestanogullari <alp at well-typed.com> wrote:

> My original motivation for !1580 and !1827 (the latter of which ended up
> getting merged) would be equally well supported by an interface with more
> limited scope. My only requirement there was to be able to override the
> meta hook. I therefore would not mind going back to the approach I
> initially took, in !1580, which I preferred back then already. As long as
> we leave a way for plugins to override hooks, my use case will not suffer.
> On 14/09/2020 21:20, Ben Gamari wrote:
>
> Moritz Angermann <moritz.angermann at gmail.com> <moritz.angermann at gmail.com> writes:
>
>
> I believe this to already be broken in HEAD. DynFlags already got quite an
> overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
> offer alternative stable interfaces. Though to be honest, I believe our
> Plugin story is rather poor so far.
>
>
> To fill in a bit of history here, DynFlags plugins were introduced in
> !1827, which arose as an alternative to !1580. The latter proposed a
> much more specialised interface specifically allowing plugins to
> introduce Hooks. Personally, I far prefer the approach taken in !1580. To
> quote my comment on !1580:
>
>
> I agree that overriding DynFlags is excessive and, moreover, it
> entrenches the structure of DynFlags as a semi-stable interface. In my
> opinion the current state of DynFlags is a very uneasy compromise and
> really should be refactored (at very least split up into smaller
> records). While it's true that the Hsc capability given to parser
> plugins allows DynFlags to be modified, I would consider this to be
> very much a backdoor and not a supported use.
>
> Hooks, on the other hand, are intended to be extension points for the
> compiler. Consequently it is quite natural for them to be set by
> plugins.
>
> In light of how quickly DynFlags is now changing, I somewhat regret not
> pushing back more vigorously against the DynFlags-centric approach. I
> tend to agree that we should remove the interface and revert to a more
> limited interface that simply deals in Hooks.
>
> Cheers,
>
> - Ben
>
>
>
> _______________________________________________
> ghc-devs mailing listghc-devs at haskell.orghttp://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/20200915/9981012f/attachment.html>

From cheng.shao at tweag.io  Wed Sep 16 18:56:49 2020
From: cheng.shao at tweag.io (Cheng Shao)
Date: Wed, 16 Sep 2020 20:56:49 +0200
Subject: Weird "missing hi file" problem with a serializable Core patch
Message-ID: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>

Hi all,

Following a short chat in #ghc last week, I did a first attempt of
reusing existing Iface logic to implement serialization for
codegen-related Core. The implementation is included in the attached
patch (~100 loc). As a quick and dirty validation of whether it works,
I also modified the codegen pipeline logic to do a roundtrip: after
CorePrep, the Core bits are converted to Iface, then we immediately
convert it back and use it for later compiling.

With the patch applied, stage-1 GHC would produce a "missing hi file"
error like:

: Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
      _build/stage1/libraries/ghc-prim/build/GHC/Types.hi:
openBinaryFile: does not exist (No such file or directory)

The error surprises me, since by the time we perform the Core-to-Core
roundtrip, the .hi file should already have been written to disk. Is
there anything obviously wrong with the implementation? I'd appreciate
any pointers or further questions, thanks a lot!

Best regards,
Cheng
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ExtCore.patch
Type: text/x-patch
Size: 4411 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200916/c4810acb/attachment.bin>

From allbery.b at gmail.com  Wed Sep 16 19:03:30 2020
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 16 Sep 2020 15:03:30 -0400
Subject: Weird "missing hi file" problem with a serializable Core patch
In-Reply-To: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>
References: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>
Message-ID: <CAKFCL4Ufbjozw408poeWyZTfnGTksApON68Y_6omj6-JTxEdTQ@mail.gmail.com>

Without looking at the implementation, it looks to me like the filename is
doubled for some reason. This may suggest places to look.

On Wed, Sep 16, 2020 at 2:57 PM Cheng Shao <cheng.shao at tweag.io> wrote:

> Hi all,
>
> Following a short chat in #ghc last week, I did a first attempt of
> reusing existing Iface logic to implement serialization for
> codegen-related Core. The implementation is included in the attached
> patch (~100 loc). As a quick and dirty validation of whether it works,
> I also modified the codegen pipeline logic to do a roundtrip: after
> CorePrep, the Core bits are converted to Iface, then we immediately
> convert it back and use it for later compiling.
>
> With the patch applied, stage-1 GHC would produce a "missing hi file"
> error like:
>
> : Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
>       _build/stage1/libraries/ghc-prim/build/GHC/Types.hi:
> openBinaryFile: does not exist (No such file or directory)
>
> The error surprises me, since by the time we perform the Core-to-Core
> roundtrip, the .hi file should already have been written to disk. Is
> there anything obviously wrong with the implementation? I'd appreciate
> any pointers or further questions, thanks a lot!
>
> Best regards,
> Cheng
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200916/b25ad164/attachment.html>

From cheng.shao at tweag.io  Wed Sep 16 19:08:53 2020
From: cheng.shao at tweag.io (Cheng Shao)
Date: Wed, 16 Sep 2020 21:08:53 +0200
Subject: Weird "missing hi file" problem with a serializable Core patch
In-Reply-To: <CAKFCL4Ufbjozw408poeWyZTfnGTksApON68Y_6omj6-JTxEdTQ@mail.gmail.com>
References: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>
 <CAKFCL4Ufbjozw408poeWyZTfnGTksApON68Y_6omj6-JTxEdTQ@mail.gmail.com>
Message-ID: <CALHrtFk0QV+ZWYh0f8rrJMWJ_RcW9O8UNEUpA_s4OfMkD3WFfw@mail.gmail.com>

Thanks Brandon,

I checked the strace log and before the error is written, there's a log entry:

openat(AT_FDCWD,
"_build/stage1/libraries/ghc-prim/build/GHC/Types.hi",
O_RDONLY|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)

So it looks like GHC is indeed looking at the correct hi path, not the
doubled path.

On Wed, Sep 16, 2020 at 9:03 PM Brandon Allbery <allbery.b at gmail.com> wrote:
>
> Without looking at the implementation, it looks to me like the filename is doubled for some reason. This may suggest places to look.
>
> On Wed, Sep 16, 2020 at 2:57 PM Cheng Shao <cheng.shao at tweag.io> wrote:
>>
>> Hi all,
>>
>> Following a short chat in #ghc last week, I did a first attempt of
>> reusing existing Iface logic to implement serialization for
>> codegen-related Core. The implementation is included in the attached
>> patch (~100 loc). As a quick and dirty validation of whether it works,
>> I also modified the codegen pipeline logic to do a roundtrip: after
>> CorePrep, the Core bits are converted to Iface, then we immediately
>> convert it back and use it for later compiling.
>>
>> With the patch applied, stage-1 GHC would produce a "missing hi file"
>> error like:
>>
>> : Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
>>       _build/stage1/libraries/ghc-prim/build/GHC/Types.hi:
>> openBinaryFile: does not exist (No such file or directory)
>>
>> The error surprises me, since by the time we perform the Core-to-Core
>> roundtrip, the .hi file should already have been written to disk. Is
>> there anything obviously wrong with the implementation? I'd appreciate
>> any pointers or further questions, thanks a lot!
>>
>> Best regards,
>> Cheng
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com

From ben at smart-cactus.org  Wed Sep 16 21:48:25 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 16 Sep 2020 17:48:25 -0400
Subject: Weird "missing hi file" problem with a serializable Core patch
In-Reply-To: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>
References: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>
Message-ID: <87wo0tjsv4.fsf@smart-cactus.org>

Cheng Shao <cheng.shao at tweag.io> writes:

> Hi all,
>
> Following a short chat in #ghc last week, I did a first attempt of
> reusing existing Iface logic to implement serialization for
> codegen-related Core. The implementation is included in the attached
> patch (~100 loc). As a quick and dirty validation of whether it works,
> I also modified the codegen pipeline logic to do a roundtrip: after
> CorePrep, the Core bits are converted to Iface, then we immediately
> convert it back and use it for later compiling.
>
> With the patch applied, stage-1 GHC would produce a "missing hi file"
> error like:
>
> : Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
>       _build/stage1/libraries/ghc-prim/build/GHC/Types.hi:
> openBinaryFile: does not exist (No such file or directory)
>
Hi Cheng,

Which module is being compiled when this error is produced? Could you
provide -ddump-if-trace output for the failing compilation?

> The error surprises me, since by the time we perform the Core-to-Core
> roundtrip, the .hi file should already have been written to disk. Is
> there anything obviously wrong with the implementation? I'd appreciate
> any pointers or further questions, thanks a lot!
>
Note that interface files are written after the Core pipeline is run.

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/20200916/9b481127/attachment.sig>

From cheng.shao at tweag.io  Thu Sep 17 10:17:11 2020
From: cheng.shao at tweag.io (Cheng Shao)
Date: Thu, 17 Sep 2020 12:17:11 +0200
Subject: Weird "missing hi file" problem with a serializable Core patch
In-Reply-To: <87wo0tjsv4.fsf@smart-cactus.org>
References: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>
 <87wo0tjsv4.fsf@smart-cactus.org>
Message-ID: <CALHrtFkp8PbHAu1SgLGr+59++zPRUOi_n3_bjaL6dxxkGB4x4A@mail.gmail.com>

Hi Ben,

The -ddump-if-trace output is attached here. The error is produced
when compiling GHC.Types in ghc-prim.

> Note that interface files are written after the Core pipeline is run.

Sorry for the confusion, I didn't mean the Core simplifier pipeline. I
mean the "Core -> Iface -> Core" roundtrip I tried to perform using
the output of CorePrep. By the time we do CorePrep, the hi files
should already have been written.

On Wed, Sep 16, 2020 at 11:48 PM Ben Gamari <ben at smart-cactus.org> wrote:
>
> Cheng Shao <cheng.shao at tweag.io> writes:
>
> > Hi all,
> >
> > Following a short chat in #ghc last week, I did a first attempt of
> > reusing existing Iface logic to implement serialization for
> > codegen-related Core. The implementation is included in the attached
> > patch (~100 loc). As a quick and dirty validation of whether it works,
> > I also modified the codegen pipeline logic to do a roundtrip: after
> > CorePrep, the Core bits are converted to Iface, then we immediately
> > convert it back and use it for later compiling.
> >
> > With the patch applied, stage-1 GHC would produce a "missing hi file"
> > error like:
> >
> > : Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
> >       _build/stage1/libraries/ghc-prim/build/GHC/Types.hi:
> > openBinaryFile: does not exist (No such file or directory)
> >
> Hi Cheng,
>
> Which module is being compiled when this error is produced? Could you
> provide -ddump-if-trace output for the failing compilation?
>
> > The error surprises me, since by the time we perform the Core-to-Core
> > roundtrip, the .hi file should already have been written to disk. Is
> > there anything obviously wrong with the implementation? I'd appreciate
> > any pointers or further questions, thanks a lot!
> >
> Note that interface files are written after the Core pipeline is run.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
| Run Ghc CompileHs Stage1: libraries/ghc-prim/GHC/Types.hs => _build/stage1/libraries/ghc-prim/build/GHC/Types.o
FYI: cannot read old interface file:
    _build/stage1/libraries/ghc-prim/build/GHC/Types.hi: openBinaryFile: does not exist (No such file or directory)
loadHiBootInterface GHC.Types
Reading [boot] interface for ghc-prim:GHC.Types;
    reason: Need the hi-boot interface for GHC.Types to compare against the Real Thing
readIFace _build/stage1/libraries/ghc-prim/build/GHC/Types.hi-boot
Considering whether to load GHC.Prim
Reading interface for ghc-prim:GHC.Prim;
    reason: GHC.Prim is directly imported
updating EPS
updating EPS
newGlobalBinder GHC.Types TyCon libraries/ghc-prim/GHC/Types.hs:(527,1)-(532,26)
                TyCon
newGlobalBinder GHC.Types TyCon libraries/ghc-prim/GHC/Types.hs:(527,14)-(532,26)
                TyCon
newGlobalBinder GHC.Types TypeLitSort libraries/ghc-prim/GHC/Types.hs:(523,1)-(524,29)
                TypeLitSort
newGlobalBinder GHC.Types TypeLitSymbol libraries/ghc-prim/GHC/Types.hs:523:20-32
                TypeLitSymbol
newGlobalBinder GHC.Types TypeLitNat libraries/ghc-prim/GHC/Types.hs:524:20-29
                TypeLitNat
newGlobalBinder GHC.Types KindRep libraries/ghc-prim/GHC/Types.hs:(515,1)-(521,49)
                KindRep
newGlobalBinder GHC.Types KindRepTyConApp libraries/ghc-prim/GHC/Types.hs:515:16-46
                KindRepTyConApp
newGlobalBinder GHC.Types KindRepVar libraries/ghc-prim/GHC/Types.hs:516:16-35
                KindRepVar
newGlobalBinder GHC.Types KindRepApp libraries/ghc-prim/GHC/Types.hs:517:16-41
                KindRepApp
newGlobalBinder GHC.Types KindRepFun libraries/ghc-prim/GHC/Types.hs:518:16-41
                KindRepFun
newGlobalBinder GHC.Types KindRepTYPE libraries/ghc-prim/GHC/Types.hs:519:16-38
                KindRepTYPE
newGlobalBinder GHC.Types KindRepTypeLitS libraries/ghc-prim/GHC/Types.hs:520:16-48
                KindRepTypeLitS
newGlobalBinder GHC.Types KindRepTypeLitD libraries/ghc-prim/GHC/Types.hs:521:16-49
                KindRepTypeLitD
newGlobalBinder GHC.Types KindBndr libraries/ghc-prim/GHC/Types.hs:503:1-19
                KindBndr
newGlobalBinder GHC.Types TrName libraries/ghc-prim/GHC/Types.hs:(498,1)-(500,18)
                TrName
newGlobalBinder GHC.Types TrNameS libraries/ghc-prim/GHC/Types.hs:499:5-17
                TrNameS
newGlobalBinder GHC.Types TrNameD libraries/ghc-prim/GHC/Types.hs:500:5-18
                TrNameD
newGlobalBinder GHC.Types Module libraries/ghc-prim/GHC/Types.hs:(494,1)-(496,22)
                Module
newGlobalBinder GHC.Types Module libraries/ghc-prim/GHC/Types.hs:(494,15)-(496,22)
                Module
newGlobalBinder GHC.Types Void# libraries/ghc-prim/GHC/Types.hs:467:1-18
                Void#
newGlobalBinder GHC.Types VecElem libraries/ghc-prim/GHC/Types.hs:(454,1)-(463,28)
                VecElem
newGlobalBinder GHC.Types Int8ElemRep libraries/ghc-prim/GHC/Types.hs:454:16-26
                Int8ElemRep
newGlobalBinder GHC.Types Int16ElemRep libraries/ghc-prim/GHC/Types.hs:455:16-27
                Int16ElemRep
newGlobalBinder GHC.Types Int32ElemRep libraries/ghc-prim/GHC/Types.hs:456:16-27
                Int32ElemRep
newGlobalBinder GHC.Types Int64ElemRep libraries/ghc-prim/GHC/Types.hs:457:16-27
                Int64ElemRep
newGlobalBinder GHC.Types Word8ElemRep libraries/ghc-prim/GHC/Types.hs:458:16-27
                Word8ElemRep
newGlobalBinder GHC.Types Word16ElemRep libraries/ghc-prim/GHC/Types.hs:459:16-28
                Word16ElemRep
newGlobalBinder GHC.Types Word32ElemRep libraries/ghc-prim/GHC/Types.hs:460:16-28
                Word32ElemRep
newGlobalBinder GHC.Types Word64ElemRep libraries/ghc-prim/GHC/Types.hs:461:16-28
                Word64ElemRep
newGlobalBinder GHC.Types FloatElemRep libraries/ghc-prim/GHC/Types.hs:462:16-27
                FloatElemRep
newGlobalBinder GHC.Types DoubleElemRep libraries/ghc-prim/GHC/Types.hs:463:16-28
                DoubleElemRep
newGlobalBinder GHC.Types VecCount libraries/ghc-prim/GHC/Types.hs:(445,1)-(450,21)
                VecCount
newGlobalBinder GHC.Types Vec2 libraries/ghc-prim/GHC/Types.hs:445:17-20
                Vec2
newGlobalBinder GHC.Types Vec4 libraries/ghc-prim/GHC/Types.hs:446:17-20
                Vec4
newGlobalBinder GHC.Types Vec8 libraries/ghc-prim/GHC/Types.hs:447:17-20
                Vec8
newGlobalBinder GHC.Types Vec16 libraries/ghc-prim/GHC/Types.hs:448:17-21
                Vec16
newGlobalBinder GHC.Types Vec32 libraries/ghc-prim/GHC/Types.hs:449:17-21
                Vec32
newGlobalBinder GHC.Types Vec64 libraries/ghc-prim/GHC/Types.hs:450:17-21
                Vec64
newGlobalBinder GHC.Types RuntimeRep libraries/ghc-prim/GHC/Types.hs:(421,1)-(438,27)
                RuntimeRep
newGlobalBinder GHC.Types VecRep libraries/ghc-prim/GHC/Types.hs:421:19-41
                VecRep
newGlobalBinder GHC.Types TupleRep libraries/ghc-prim/GHC/Types.hs:422:19-39
                TupleRep
newGlobalBinder GHC.Types SumRep libraries/ghc-prim/GHC/Types.hs:423:19-37
                SumRep
newGlobalBinder GHC.Types LiftedRep libraries/ghc-prim/GHC/Types.hs:424:19-27
                LiftedRep
newGlobalBinder GHC.Types UnliftedRep libraries/ghc-prim/GHC/Types.hs:425:19-29
                UnliftedRep
newGlobalBinder GHC.Types IntRep libraries/ghc-prim/GHC/Types.hs:426:19-24
                IntRep
newGlobalBinder GHC.Types Int8Rep libraries/ghc-prim/GHC/Types.hs:427:19-25
                Int8Rep
newGlobalBinder GHC.Types Int16Rep libraries/ghc-prim/GHC/Types.hs:428:19-26
                Int16Rep
newGlobalBinder GHC.Types Int32Rep libraries/ghc-prim/GHC/Types.hs:429:19-26
                Int32Rep
newGlobalBinder GHC.Types Int64Rep libraries/ghc-prim/GHC/Types.hs:430:19-26
                Int64Rep
newGlobalBinder GHC.Types WordRep libraries/ghc-prim/GHC/Types.hs:431:19-25
                WordRep
newGlobalBinder GHC.Types Word8Rep libraries/ghc-prim/GHC/Types.hs:432:19-26
                Word8Rep
newGlobalBinder GHC.Types Word16Rep libraries/ghc-prim/GHC/Types.hs:433:19-27
                Word16Rep
newGlobalBinder GHC.Types Word32Rep libraries/ghc-prim/GHC/Types.hs:434:19-27
                Word32Rep
newGlobalBinder GHC.Types Word64Rep libraries/ghc-prim/GHC/Types.hs:435:19-27
                Word64Rep
newGlobalBinder GHC.Types AddrRep libraries/ghc-prim/GHC/Types.hs:436:19-25
                AddrRep
newGlobalBinder GHC.Types FloatRep libraries/ghc-prim/GHC/Types.hs:437:19-26
                FloatRep
newGlobalBinder GHC.Types DoubleRep libraries/ghc-prim/GHC/Types.hs:438:19-27
                DoubleRep
newGlobalBinder GHC.Types SPEC libraries/ghc-prim/GHC/Types.hs:400:1-24
                SPEC
newGlobalBinder GHC.Types SPEC libraries/ghc-prim/GHC/Types.hs:400:13-16
                SPEC
newGlobalBinder GHC.Types SPEC2 libraries/ghc-prim/GHC/Types.hs:400:20-24
                SPEC2
newGlobalBinder GHC.Types Bool libraries/ghc-prim/GHC/Types.hs:324:1-47
                Bool
newGlobalBinder GHC.Types False libraries/ghc-prim/GHC/Types.hs:324:36-40
                False
newGlobalBinder GHC.Types True libraries/ghc-prim/GHC/Types.hs:324:44-47
                True
newGlobalBinder GHC.Types Coercible libraries/ghc-prim/GHC/Types.hs:315:1-33
                Coercible
newGlobalBinder GHC.Types ~~ libraries/ghc-prim/GHC/Types.hs:259:1-12
                ~~
newGlobalBinder GHC.Types IO libraries/ghc-prim/GHC/Types.hs:224:1-65
                IO
newGlobalBinder GHC.Types IO libraries/ghc-prim/GHC/Types.hs:224:16-65
                IO
newGlobalBinder GHC.Types Double libraries/ghc-prim/GHC/Types.hs:201:1-49
                Double
newGlobalBinder GHC.Types D# libraries/ghc-prim/GHC/Types.hs:201:40-49
                D#
newGlobalBinder GHC.Types Float libraries/ghc-prim/GHC/Types.hs:196:1-46
                Float
newGlobalBinder GHC.Types F# libraries/ghc-prim/GHC/Types.hs:196:38-46
                F#
newGlobalBinder GHC.Types Word libraries/ghc-prim/GHC/Types.hs:191:1-43
                Word
newGlobalBinder GHC.Types W# libraries/ghc-prim/GHC/Types.hs:191:36-43
                W#
newGlobalBinder GHC.Types Int libraries/ghc-prim/GHC/Types.hs:188:1-40
                Int
newGlobalBinder GHC.Types I# libraries/ghc-prim/GHC/Types.hs:188:34-40
                I#
newGlobalBinder GHC.Types Char libraries/ghc-prim/GHC/Types.hs:183:1-43
                Char
newGlobalBinder GHC.Types C# libraries/ghc-prim/GHC/Types.hs:183:36-43
                C#
newGlobalBinder GHC.Types Ordering libraries/ghc-prim/GHC/Types.hs:162:1-28
                Ordering
newGlobalBinder GHC.Types LT libraries/ghc-prim/GHC/Types.hs:162:17-18
                LT
newGlobalBinder GHC.Types EQ libraries/ghc-prim/GHC/Types.hs:162:22-23
                EQ
newGlobalBinder GHC.Types GT libraries/ghc-prim/GHC/Types.hs:162:27-28
                GT
newGlobalBinder GHC.Types Any libraries/ghc-prim/GHC/Types.hs:123:1-20
                Any
newGlobalBinder GHC.Types Symbol libraries/ghc-prim/GHC/Types.hs:110:1-11
                Symbol
newGlobalBinder GHC.Types Nat libraries/ghc-prim/GHC/Types.hs:106:1-8
                Nat
newGlobalBinder GHC.Types MultMul libraries/ghc-prim/GHC/Types.hs:93:1-75
                MultMul
newGlobalBinder GHC.Types Multiplicity libraries/ghc-prim/GHC/Types.hs:91:1-30
                Multiplicity
newGlobalBinder GHC.Types Many libraries/ghc-prim/GHC/Types.hs:91:21-24
                Many
newGlobalBinder GHC.Types One libraries/ghc-prim/GHC/Types.hs:91:28-30
                One
newGlobalBinder GHC.Types Type libraries/ghc-prim/GHC/Types.hs:89:1-27
                Type
newGlobalBinder GHC.Types Constraint libraries/ghc-prim/GHC/Types.hs:86:1-15
                Constraint
newGlobalBinder GHC.Types isTrue# libraries/ghc-prim/GHC/Types.hs:330:1-7
                isTrue#
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
newGlobalBinder GHC.Types D:R:MultMul libraries/ghc-prim/GHC/Types.hs:93:13-19
                D:R:MultMul
checkWiredInTyCon []
GHC.Types
newGlobalBinder GHC.Types $tc'LT <no location info>
                $tc'LT
newGlobalBinder GHC.Types $WLT libraries/ghc-prim/GHC/Types.hs:162:17-18
                $WLT
newGlobalBinder GHC.Types LT libraries/ghc-prim/GHC/Types.hs:162:17-18
                LT
buildDataCon 1 LT
buildDataCon 2 LT
newGlobalBinder GHC.Types $tc'EQ <no location info>
                $tc'EQ
newGlobalBinder GHC.Types $WEQ libraries/ghc-prim/GHC/Types.hs:162:22-23
                $WEQ
newGlobalBinder GHC.Types EQ libraries/ghc-prim/GHC/Types.hs:162:22-23
                EQ
buildDataCon 1 EQ
buildDataCon 2 EQ
newGlobalBinder GHC.Types $tc'GT <no location info>
                $tc'GT
newGlobalBinder GHC.Types $WGT libraries/ghc-prim/GHC/Types.hs:162:27-28
                $WGT
newGlobalBinder GHC.Types GT libraries/ghc-prim/GHC/Types.hs:162:27-28
                GT
buildDataCon 1 GT
buildDataCon 2 GT
newGlobalBinder GHC.Types $tcOrdering <no location info>
                $tcOrdering
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
newGlobalBinder GHC.Types $tc'IO <no location info>
                $tc'IO
newGlobalBinder GHC.Types $WIO libraries/ghc-prim/GHC/Types.hs:224:16-65
                $WIO
newGlobalBinder GHC.Types IO libraries/ghc-prim/GHC/Types.hs:224:16-65
                IO
buildDataCon 1 IO
buildDataCon 2 IO
newGlobalBinder GHC.Types N:IO libraries/ghc-prim/GHC/Types.hs:224:1-65
                N:IO
mkNewTyConRhs N:IO
newGlobalBinder GHC.Types $tcIO <no location info>
                $tcIO
newGlobalBinder GHC.Types $tc'SPEC <no location info>
                $tc'SPEC
newGlobalBinder GHC.Types $WSPEC libraries/ghc-prim/GHC/Types.hs:400:13-16
                $WSPEC
newGlobalBinder GHC.Types SPEC libraries/ghc-prim/GHC/Types.hs:400:13-16
                SPEC
buildDataCon 1 SPEC
buildDataCon 2 SPEC
newGlobalBinder GHC.Types $tc'SPEC2 <no location info>
                $tc'SPEC2
newGlobalBinder GHC.Types $WSPEC2 libraries/ghc-prim/GHC/Types.hs:400:20-24
                $WSPEC2
newGlobalBinder GHC.Types SPEC2 libraries/ghc-prim/GHC/Types.hs:400:20-24
                SPEC2
buildDataCon 1 SPEC2
buildDataCon 2 SPEC2
newGlobalBinder GHC.Types $tcSPEC <no location info>
                $tcSPEC
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
newGlobalBinder GHC.Types $tc'TrNameS <no location info>
                $tc'TrNameS
newGlobalBinder GHC.Types $WTrNameS libraries/ghc-prim/GHC/Types.hs:499:5-17
                $WTrNameS
newGlobalBinder GHC.Types TrNameS libraries/ghc-prim/GHC/Types.hs:499:5-17
                TrNameS
buildDataCon 1 TrNameS
buildDataCon 2 TrNameS
checkWiredInTyCon []
GHC.Types
newGlobalBinder GHC.Types $tc'TrNameD <no location info>
                $tc'TrNameD
newGlobalBinder GHC.Types $WTrNameD libraries/ghc-prim/GHC/Types.hs:500:5-18
                $WTrNameD
newGlobalBinder GHC.Types TrNameD libraries/ghc-prim/GHC/Types.hs:500:5-18
                TrNameD
buildDataCon 1 TrNameD
buildDataCon 2 TrNameD
newGlobalBinder GHC.Types $tcTrName <no location info>
                $tcTrName
newGlobalBinder GHC.Types $tc'Module <no location info>
                $tc'Module
newGlobalBinder GHC.Types $WModule libraries/ghc-prim/GHC/Types.hs:(494,15)-(496,22)
                $WModule
newGlobalBinder GHC.Types Module libraries/ghc-prim/GHC/Types.hs:(494,15)-(496,22)
                Module
buildDataCon 1 Module
buildDataCon 2 Module
newGlobalBinder GHC.Types $tcModule <no location info>
                $tcModule
newGlobalBinder GHC.Types $tc'TypeLitSymbol <no location info>
                $tc'TypeLitSymbol
newGlobalBinder GHC.Types $WTypeLitSymbol libraries/ghc-prim/GHC/Types.hs:523:20-32
                $WTypeLitSymbol
newGlobalBinder GHC.Types TypeLitSymbol libraries/ghc-prim/GHC/Types.hs:523:20-32
                TypeLitSymbol
buildDataCon 1 TypeLitSymbol
buildDataCon 2 TypeLitSymbol
newGlobalBinder GHC.Types $tc'TypeLitNat <no location info>
                $tc'TypeLitNat
newGlobalBinder GHC.Types $WTypeLitNat libraries/ghc-prim/GHC/Types.hs:524:20-29
                $WTypeLitNat
newGlobalBinder GHC.Types TypeLitNat libraries/ghc-prim/GHC/Types.hs:524:20-29
                TypeLitNat
buildDataCon 1 TypeLitNat
buildDataCon 2 TypeLitNat
newGlobalBinder GHC.Types $tcTypeLitSort <no location info>
                $tcTypeLitSort
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
Considering whether to load GHC.Prim {- SYSTEM -}
newGlobalBinder GHC.Types $tc'TyCon <no location info>
                $tc'TyCon
newGlobalBinder GHC.Types $WTyCon libraries/ghc-prim/GHC/Types.hs:(527,14)-(532,26)
                $WTyCon
newGlobalBinder GHC.Types TyCon libraries/ghc-prim/GHC/Types.hs:(527,14)-(532,26)
                TyCon
buildDataCon 1 TyCon
buildDataCon 2 TyCon
newGlobalBinder GHC.Types $tcTyCon <no location info>
                $tcTyCon
checkWiredInTyCon []
GHC.Types
newGlobalBinder GHC.Types $tc'KindRepTyConApp <no location info>
                $tc'KindRepTyConApp
newGlobalBinder GHC.Types $WKindRepTyConApp libraries/ghc-prim/GHC/Types.hs:515:16-46
                $WKindRepTyConApp
newGlobalBinder GHC.Types KindRepTyConApp libraries/ghc-prim/GHC/Types.hs:515:16-46
                KindRepTyConApp
buildDataCon 1 KindRepTyConApp
buildDataCon 2 KindRepTyConApp
newGlobalBinder GHC.Types $tc'KindRepVar <no location info>
                $tc'KindRepVar
newGlobalBinder GHC.Types $WKindRepVar libraries/ghc-prim/GHC/Types.hs:516:16-35
                $WKindRepVar
newGlobalBinder GHC.Types KindRepVar libraries/ghc-prim/GHC/Types.hs:516:16-35
                KindRepVar
buildDataCon 1 KindRepVar
buildDataCon 2 KindRepVar
newGlobalBinder GHC.Types $tc'KindRepApp <no location info>
                $tc'KindRepApp
newGlobalBinder GHC.Types $WKindRepApp libraries/ghc-prim/GHC/Types.hs:517:16-41
                $WKindRepApp
newGlobalBinder GHC.Types KindRepApp libraries/ghc-prim/GHC/Types.hs:517:16-41
                KindRepApp
buildDataCon 1 KindRepApp
buildDataCon 2 KindRepApp
newGlobalBinder GHC.Types $tc'KindRepFun <no location info>
                $tc'KindRepFun
newGlobalBinder GHC.Types $WKindRepFun libraries/ghc-prim/GHC/Types.hs:518:16-41
                $WKindRepFun
newGlobalBinder GHC.Types KindRepFun libraries/ghc-prim/GHC/Types.hs:518:16-41
                KindRepFun
buildDataCon 1 KindRepFun
buildDataCon 2 KindRepFun
newGlobalBinder GHC.Types $tc'KindRepTYPE <no location info>
                $tc'KindRepTYPE
newGlobalBinder GHC.Types $WKindRepTYPE libraries/ghc-prim/GHC/Types.hs:519:16-38
                $WKindRepTYPE
newGlobalBinder GHC.Types KindRepTYPE libraries/ghc-prim/GHC/Types.hs:519:16-38
                KindRepTYPE
buildDataCon 1 KindRepTYPE
buildDataCon 2 KindRepTYPE
Considering whether to load GHC.Prim {- SYSTEM -}
newGlobalBinder GHC.Types $tc'KindRepTypeLitS <no location info>
                $tc'KindRepTypeLitS
newGlobalBinder GHC.Types $WKindRepTypeLitS libraries/ghc-prim/GHC/Types.hs:520:16-48
                $WKindRepTypeLitS
newGlobalBinder GHC.Types KindRepTypeLitS libraries/ghc-prim/GHC/Types.hs:520:16-48
                KindRepTypeLitS
buildDataCon 1 KindRepTypeLitS
buildDataCon 2 KindRepTypeLitS
checkWiredInTyCon []
GHC.Types
newGlobalBinder GHC.Types $tc'KindRepTypeLitD <no location info>
                $tc'KindRepTypeLitD
newGlobalBinder GHC.Types $WKindRepTypeLitD libraries/ghc-prim/GHC/Types.hs:521:16-49
                $WKindRepTypeLitD
newGlobalBinder GHC.Types KindRepTypeLitD libraries/ghc-prim/GHC/Types.hs:521:16-49
                KindRepTypeLitD
buildDataCon 1 KindRepTypeLitD
buildDataCon 2 KindRepTypeLitD
newGlobalBinder GHC.Types $tcKindRep <no location info>
                $tcKindRep
Considering whether to load GHC.Prim {- SYSTEM -}
newGlobalBinder GHC.Types $trModule libraries/ghc-prim/GHC/Types.hs:1:1
                $trModule
Need decl for $WKindRepVar
Considering whether to load GHC.Types {- SYSTEM -}
Reading interface for ghc-prim:GHC.Types;
    reason: Need decl for $WKindRepVar
readIFace _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
updating EPS
: Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
      _build/stage1/libraries/ghc-prim/build/GHC/Types.hi: openBinaryFile: does not exist (No such file or directory)
user error (tcExtCoreBindsDriver)
Error when running Shake build system:
  at action, called at src/Rules.hs:40:19 in main:Rules
  at need, called at src/Rules.hs:62:5 in main:Rules
* Depends on: _build/stage1/lib/package.conf.d/ghc-bignum-1.0.conf
  at apply1, called at src/Development/Shake/Internal/Rules/Oracle.hs:159:32 in shake-0.18.5-dcf2fec5384b4e9a9a7a7726785dce850f9063d30a2e432cf73d0a0cf0079f32:Development.Shake.Internal.Rules.Oracle
* Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "ghc-bignum", pkgPath = "libraries/ghc-bignum"}, way = v}))
  at need, called at src/Hadrian/Oracles/Cabal/Rules.hs:54:9 in main:Hadrian.Oracles.Cabal.Rules
* Depends on: _build/stage1/libraries/ghc-bignum/setup-config
  at need, called at src/Rules/Library.hs:157:18 in main:Rules.Library
* Depends on: _build/stage1/libraries/ghc-prim/build/HSghc-prim-0.7.0.o
  at need, called at src/Rules/Library.hs:104:5 in main:Rules.Library
* Depends on: _build/stage1/libraries/ghc-prim/build/GHC/Types.o
  at &%>, called at src/Rules/Compile.hs:77:9 in main:Rules.Compile
* Depends on: _build/stage1/libraries/ghc-prim/build/GHC/Types.o _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
  at cmd', called at src/Builder.hs:293:23 in main:Builder
  at cmd, called at src/Builder.hs:380:8 in main:Builder
* Raised the exception:
Development.Shake.cmd, system command failed
Command line: _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id ghc-prim-0.7.0' '-package-id rts-1.0' -i -i/home/terrorjack/ghc/_build/stage1/libraries/ghc-prim/build -i/home/terrorjack/ghc/_build/stage1/libraries/ghc-prim/build/autogen -i/home/terrorjack/ghc/libraries/ghc-prim -Iincludes -I_build/stage1/lib -I_build/stage1/libraries/ghc-prim/build -I/nix/store/sznfxigwvrvn6ar3nz3f0652zsld9xqj-gmp-6.2.0-dev/include -I/nix/store/sv6f05ngaarba50ybr6fdfc7cciv6nbv-elfutils-0.176/include -I/nix/store/bfrcskjspk9a179xqqf1q9xqafq5s8d2-numactl-2.0.13/include -I/home/terrorjack/ghc/_build/stage1/lib/x86_64-linux-ghc-8.11.0.20200917/rts-1.0/include -I_build/stage1/lib -optc-I_build/stage1/lib -optP-include -optP_build/stage1/libraries/ghc-prim/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/ghc-prim/build -Wnoncanonical-monad-instances -optc-Wno-error=inline -optP-Wno-nonportable-include-path -c libraries/ghc-prim/GHC/Types.hs -o _build/stage1/libraries/ghc-prim/build/GHC/Types.o -O0 -H64m -this-unit-id ghc-prim -XHaskell2010 -no-global-package-db -package-db=/home/terrorjack/ghc/_build/stage1/lib/package.conf.d -ghcversion-file=/home/terrorjack/ghc/_build/stage1/lib/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe -ddump-to-file -ddump-if-trace
Exit code: 1

From sylvain at haskus.fr  Thu Sep 17 10:53:37 2020
From: sylvain at haskus.fr (Sylvain Henry)
Date: Thu, 17 Sep 2020 12:53:37 +0200
Subject: Weird "missing hi file" problem with a serializable Core patch
In-Reply-To: <CALHrtFkp8PbHAu1SgLGr+59++zPRUOi_n3_bjaL6dxxkGB4x4A@mail.gmail.com>
References: <CALHrtFmYRwOb7+_wvsOCxpLEn6notk+RNPw5UmVJ3Bs7FwTssg@mail.gmail.com>
 <87wo0tjsv4.fsf@smart-cactus.org>
 <CALHrtFkp8PbHAu1SgLGr+59++zPRUOi_n3_bjaL6dxxkGB4x4A@mail.gmail.com>
Message-ID: <dd5d03a8-1966-b12f-8ec5-ebf30b37b0a2@haskus.fr>

> By the time we do CorePrep, the hi files should already have been written.

I don't think so. When we generate real code we write the interface after the backend has generated the output object. See Note [Writing interface files] in GHC.Driver.Main

Cheers,
Sylvain

On 17/09/2020 12:17, Cheng Shao wrote:
> Hi Ben,
>
> The -ddump-if-trace output is attached here. The error is produced
> when compiling GHC.Types in ghc-prim.
>
>> Note that interface files are written after the Core pipeline is run.
> Sorry for the confusion, I didn't mean the Core simplifier pipeline. I
> mean the "Core -> Iface -> Core" roundtrip I tried to perform using
> the output of CorePrep. By the time we do CorePrep, the hi files
> should already have been written.
>
> On Wed, Sep 16, 2020 at 11:48 PM Ben Gamari <ben at smart-cactus.org> wrote:
>> Cheng Shao <cheng.shao at tweag.io> writes:
>>
>>> Hi all,
>>>
>>> Following a short chat in #ghc last week, I did a first attempt of
>>> reusing existing Iface logic to implement serialization for
>>> codegen-related Core. The implementation is included in the attached
>>> patch (~100 loc). As a quick and dirty validation of whether it works,
>>> I also modified the codegen pipeline logic to do a roundtrip: after
>>> CorePrep, the Core bits are converted to Iface, then we immediately
>>> convert it back and use it for later compiling.
>>>
>>> With the patch applied, stage-1 GHC would produce a "missing hi file"
>>> error like:
>>>
>>> : Bad interface file: _build/stage1/libraries/ghc-prim/build/GHC/Types.hi
>>>        _build/stage1/libraries/ghc-prim/build/GHC/Types.hi:
>>> openBinaryFile: does not exist (No such file or directory)
>>>
>> Hi Cheng,
>>
>> Which module is being compiled when this error is produced? Could you
>> provide -ddump-if-trace output for the failing compilation?
>>
>>> The error surprises me, since by the time we perform the Core-to-Core
>>> roundtrip, the .hi file should already have been written to disk. Is
>>> there anything obviously wrong with the implementation? I'd appreciate
>>> any pointers or further questions, thanks a lot!
>>>
>> Note that interface files are written after the Core pipeline is run.
>>
>> 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/20200917/505583b1/attachment.html>

From adam at well-typed.com  Fri Sep 18 09:52:42 2020
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 18 Sep 2020 10:52:42 +0100
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
Message-ID: <e0b7373e-3317-2d00-aaee-ec9566348e9d@well-typed.com>

On 14/09/2020 13:02, Moritz Angermann wrote:
> I believe this to already be broken in HEAD. DynFlags already got quite
> an overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
> offer alternative stable interfaces. Though to be honest, I believe our
> Plugin story is rather poor so far.
> 
> Do you happen to know of DynFlagPlugins, Adam?

A few have been mentioned in the thread now. What specifically do you
believe is broken in HEAD regarding DynFlags plugins, and is there an
issue for it? AFAICS the hooks-plugin test which corresponds to the
user's guide text is still there.

I think it is important to retain the ability for plugins to manipulate
both DynFlags and Hooks, whether the latter are separated out of the
former or not. Both have legitimate use cases, and plugins necessarily
involve using unstable interfaces (at least until someone designs a
stable interface). I agree that the current state of plugins/hooks is
somewhat ad-hoc and could do with more effort put into the design (like
much else in the GHC API!) but that doesn't mean we should remove things
that work already.

Slightly tangential note: discussing this with Alp I learned about the
log_action/dump_action/trace_action fields of DynFlags, which also seem
to violate Simon's "We should think of DynFlags as an abstract syntax
tree." And indeed it would be useful for plugins to be able to override
log_action, especially combined with #18516, as then we would have a
nice story for plugins overriding error message generation to allow for
domain-specific error messages.

Cheers,

Adam


> On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <adam at well-typed.com
> <mailto:adam at well-typed.com>> wrote:
> 
>     I'm supportive of the goal, but a complication with removing hooks from
>     DynFlags is that GHC currently supports "DynFlags plugins" that allow
>     plugins to install custom hooks
>     (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins).
>     I guess this can be worked around, perhaps by passing hooks separately
>     to DynFlags and providing a separate plugin interface to modify hooks.
>     But doing so will necessarily break existing plugins.
> 
>     Adam
> 
> 
>     On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
>     > I thought I’d sent a message about this DynFlags thing, but I can’t
>     > trace it now.   So here’s a resend.
>     >
>     >  
>     >
>     > Currently
>     >
>     >   * The DynFlags record includes Hooks
>     >   * Hooks in contains functions, that mention TcM, DsM etc
>     >
>     >  
>     >
>     > This is bad.  We should think of DynFlags as an *abstract syntax
>     tree*. 
>     > That is, the result of parsing the flag strings, yes, but not much
>     > more.  So for hooks we should have an algebraic data type representing
>     > the hook /specification/, but it should not be the hook functions
>     > themselves.  HsSyn, for example, after parsing, is just a tree with
>     > strings in it.  No TyCons, Ids, etc. That comes much later.
>     >
>     >  
>     >
>     > So DynFlags should be a collection of algebraic data types, but should
>     > not depend on anything else.
>     >
>     >  
>     >
>     > I think that may cut a bunch of awkward loops.
>     >
>     >  
>     >
>     > Simon
>     >
>     >  
>     >
>     > *From:*Simon Peyton Jones
>     > *Sent:* 10 September 2020 14:17
>     > *To:* Sebastian Graf <sgraf1337 at gmail.com
>     <mailto:sgraf1337 at gmail.com>>; Sylvain Henry
>     > <sylvain at haskus.fr <mailto:sylvain at haskus.fr>>
>     > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>
>     > *Subject:* RE: Parser depends on DynFlags, depends on Hooks,
>     depends on
>     > TcM, DsM, ...
>     >
>     >  
>     >
>     > And for sure the **parser** should not depend on the **desugarer** and
>     > **typechecker**.   (Which it does, as described below.)
>     >
>     >  
>     >
>     https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
>     > S
>     >
>     >  
>     >
>     > *From:*ghc-devs <ghc-devs-bounces at haskell.org
>     <mailto:ghc-devs-bounces at haskell.org>
>     > <mailto:ghc-devs-bounces at haskell.org
>     <mailto:ghc-devs-bounces at haskell.org>>> *On Behalf Of *Sebastian Graf
>     > *Sent:* 10 September 2020 14:12
>     > *To:* Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>
>     <mailto:sylvain at haskus.fr <mailto:sylvain at haskus.fr>>>
>     > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>>
>     > *Subject:* Parser depends on DynFlags, depends on Hooks, depends
>     on TcM,
>     > DsM, ...
>     >
>     >  
>     >
>     > Hey Sylvain,
>     >
>     >  
>     >
>     > In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0>
>     > I had to fight once more with the transitive dependency set of the
>     > parser, the minimality of which is crucial for ghc-lib-parser
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0>
>     > and tested by the CountParserDeps test.
>     >
>     >  
>     >
>     > I discovered that I need to make (parts of) `DsM` abstract, because it
>     > is transitively imported from the Parser for example through
>     Parser.y ->
>     > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
>     >
>     > Since you are our mastermind behind the "Tame DynFlags"
>     initiative, I'd
>     > like to hear your opinion on where progress can be/is made on that
>     front.
>     >
>     >  
>     >
>     > I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0>
>     > and https://gitlab.haskell.org/ghc/ghc/-/issues/11301
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0>
>     > which ask a related, but different question: They want a DynFlags-free
>     > interface, but I even want a DynFlags-free *module*.
>     >
>     >  
>     >
>     > Would you say it's reasonable to abstract the definition of `PState`
>     > over the `DynFlags` type? I think it's only used for pretty-printing
>     > messages, which is one of your specialties (the treatment of
>     DynFlags in
>     > there, at least).
>     >
>     > Anyway, can you think of or perhaps point me to an existing road
>     map on
>     > that issue?
>     >
>     >  
>     >
>     > Thank you!
>     >
>     > Sebastian


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England

From moritz.angermann at gmail.com  Fri Sep 18 13:56:26 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 18 Sep 2020 21:56:26 +0800
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <e0b7373e-3317-2d00-aaee-ec9566348e9d@well-typed.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
 <e0b7373e-3317-2d00-aaee-ec9566348e9d@well-typed.com>
Message-ID: <CAKfdd-zG1KiTMkrnycyXSvhpguHF6rTKswCamGohy_GGcQjJHQ@mail.gmail.com>

I'm not certain anything in HEAD actually breaks any plugin today. But the
whole idea of plugins having full access to what currently is "DynFlags" is
not something I believe we can sustain. @Sylvain Henry <sylvain at haskus.fr> is
currently cleaning up a lot of unnecessary DynFlags usage. I'm not against
keeping the necessary infrastructure for hooks and other interfaces with
plugins, but I'd like to advocate towards not expecting DynFlags to keep
existing in eternity. If we assume a subset of what used to be in DynFlags
to be relevant to Plugins, let's collect that in say PluginHooks, but let's
keep that interface minimal. And maybe that can be specified to stay stable.

DynFlags is our state kitchensink in GHC, and it is everywhere. The state
is threaded through everything and the module is gargantuous. So far there
seemed to be broad support in removing this wart.

Cheers,
Moritz

On Fri, Sep 18, 2020 at 5:52 PM Adam Gundry <adam at well-typed.com> wrote:

> On 14/09/2020 13:02, Moritz Angermann wrote:
> > I believe this to already be broken in HEAD. DynFlags already got quite
> > an overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
> > offer alternative stable interfaces. Though to be honest, I believe our
> > Plugin story is rather poor so far.
> >
> > Do you happen to know of DynFlagPlugins, Adam?
>
> A few have been mentioned in the thread now. What specifically do you
> believe is broken in HEAD regarding DynFlags plugins, and is there an
> issue for it? AFAICS the hooks-plugin test which corresponds to the
> user's guide text is still there.
>
> I think it is important to retain the ability for plugins to manipulate
> both DynFlags and Hooks, whether the latter are separated out of the
> former or not. Both have legitimate use cases, and plugins necessarily
> involve using unstable interfaces (at least until someone designs a
> stable interface). I agree that the current state of plugins/hooks is
> somewhat ad-hoc and could do with more effort put into the design (like
> much else in the GHC API!) but that doesn't mean we should remove things
> that work already.
>
> Slightly tangential note: discussing this with Alp I learned about the
> log_action/dump_action/trace_action fields of DynFlags, which also seem
> to violate Simon's "We should think of DynFlags as an abstract syntax
> tree." And indeed it would be useful for plugins to be able to override
> log_action, especially combined with #18516, as then we would have a
> nice story for plugins overriding error message generation to allow for
> domain-specific error messages.
>
> Cheers,
>
> Adam
>
>
> > On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <adam at well-typed.com
> > <mailto:adam at well-typed.com>> wrote:
> >
> >     I'm supportive of the goal, but a complication with removing hooks
> from
> >     DynFlags is that GHC currently supports "DynFlags plugins" that allow
> >     plugins to install custom hooks
> >     (
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
> ).
> >     I guess this can be worked around, perhaps by passing hooks
> separately
> >     to DynFlags and providing a separate plugin interface to modify
> hooks.
> >     But doing so will necessarily break existing plugins.
> >
> >     Adam
> >
> >
> >     On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
> >     > I thought I’d sent a message about this DynFlags thing, but I can’t
> >     > trace it now.   So here’s a resend.
> >     >
> >     >
> >     >
> >     > Currently
> >     >
> >     >   * The DynFlags record includes Hooks
> >     >   * Hooks in contains functions, that mention TcM, DsM etc
> >     >
> >     >
> >     >
> >     > This is bad.  We should think of DynFlags as an *abstract syntax
> >     tree*.
> >     > That is, the result of parsing the flag strings, yes, but not much
> >     > more.  So for hooks we should have an algebraic data type
> representing
> >     > the hook /specification/, but it should not be the hook functions
> >     > themselves.  HsSyn, for example, after parsing, is just a tree with
> >     > strings in it.  No TyCons, Ids, etc. That comes much later.
> >     >
> >     >
> >     >
> >     > So DynFlags should be a collection of algebraic data types, but
> should
> >     > not depend on anything else.
> >     >
> >     >
> >     >
> >     > I think that may cut a bunch of awkward loops.
> >     >
> >     >
> >     >
> >     > Simon
> >     >
> >     >
> >     >
> >     > *From:*Simon Peyton Jones
> >     > *Sent:* 10 September 2020 14:17
> >     > *To:* Sebastian Graf <sgraf1337 at gmail.com
> >     <mailto:sgraf1337 at gmail.com>>; Sylvain Henry
> >     > <sylvain at haskus.fr <mailto:sylvain at haskus.fr>>
> >     > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org
> >>
> >     > *Subject:* RE: Parser depends on DynFlags, depends on Hooks,
> >     depends on
> >     > TcM, DsM, ...
> >     >
> >     >
> >     >
> >     > And for sure the **parser** should not depend on the **desugarer**
> and
> >     > **typechecker**.   (Which it does, as described below.)
> >     >
> >     >
> >     >
> >
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
> >     > S
> >     >
> >     >
> >     >
> >     > *From:*ghc-devs <ghc-devs-bounces at haskell.org
> >     <mailto:ghc-devs-bounces at haskell.org>
> >     > <mailto:ghc-devs-bounces at haskell.org
> >     <mailto:ghc-devs-bounces at haskell.org>>> *On Behalf Of *Sebastian
> Graf
> >     > *Sent:* 10 September 2020 14:12
> >     > *To:* Sylvain Henry <sylvain at haskus.fr <mailto:sylvain at haskus.fr>
> >     <mailto:sylvain at haskus.fr <mailto:sylvain at haskus.fr>>>
> >     > *Cc:* ghc-devs <ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> >     <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>>
> >     > *Subject:* Parser depends on DynFlags, depends on Hooks, depends
> >     on TcM,
> >     > DsM, ...
> >     >
> >     >
> >     >
> >     > Hey Sylvain,
> >     >
> >     >
> >     >
> >     > In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971
> >     >
> >     <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0
> >
> >     > I had to fight once more with the transitive dependency set of the
> >     > parser, the minimality of which is crucial for ghc-lib-parser
> >     >
> >     <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0
> >
> >     > and tested by the CountParserDeps test.
> >     >
> >     >
> >     >
> >     > I discovered that I need to make (parts of) `DsM` abstract,
> because it
> >     > is transitively imported from the Parser for example through
> >     Parser.y ->
> >     > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
> >     >
> >     > Since you are our mastermind behind the "Tame DynFlags"
> >     initiative, I'd
> >     > like to hear your opinion on where progress can be/is made on that
> >     front.
> >     >
> >     >
> >     >
> >     > I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961
> >     >
> >     <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0
> >
> >     > and https://gitlab.haskell.org/ghc/ghc/-/issues/11301
> >     >
> >     <
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0
> >
> >     > which ask a related, but different question: They want a
> DynFlags-free
> >     > interface, but I even want a DynFlags-free *module*.
> >     >
> >     >
> >     >
> >     > Would you say it's reasonable to abstract the definition of
> `PState`
> >     > over the `DynFlags` type? I think it's only used for
> pretty-printing
> >     > messages, which is one of your specialties (the treatment of
> >     DynFlags in
> >     > there, at least).
> >     >
> >     > Anyway, can you think of or perhaps point me to an existing road
> >     map on
> >     > that issue?
> >     >
> >     >
> >     >
> >     > Thank you!
> >     >
> >     > Sebastian
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 118 Wymering Mansions, Wymering Road, London W9 2NF, England
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200918/8d19da54/attachment.html>

From simonpj at microsoft.com  Fri Sep 18 14:16:44 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 18 Sep 2020 14:16:44 +0000
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <CAKfdd-zG1KiTMkrnycyXSvhpguHF6rTKswCamGohy_GGcQjJHQ@mail.gmail.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
 <e0b7373e-3317-2d00-aaee-ec9566348e9d@well-typed.com>
 <CAKfdd-zG1KiTMkrnycyXSvhpguHF6rTKswCamGohy_GGcQjJHQ@mail.gmail.com>
Message-ID: <VI1PR83MB0429E8890E69FC365C921C7BAD3F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

But NB: The wart would be much less warty if it was only an abstract syntax tree.   Then it would have practically NO dependencies!  The only wartiness is that if f :: DynFlags -> bha, it’s hard to tell how much of DynFlags f reads.  That’s a software engineering issue, but a much less painful one than having giant module dependency loops.

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Moritz Angermann
Sent: 18 September 2020 14:56
To: Adam Gundry <adam at well-typed.com>; Sylvain Henry <sylvain at haskus.fr>
Cc: ghc-devs <ghc-devs at haskell.org>
Subject: Re: Parser depends on DynFlags, depends on Hooks, depends on TcM, DsM, ...

I'm not certain anything in HEAD actually breaks any plugin today. But the whole idea of plugins having full access to what currently is "DynFlags" is not something I believe we can sustain. @Sylvain Henry<mailto:sylvain at haskus.fr> is currently cleaning up a lot of unnecessary DynFlags usage. I'm not against keeping the necessary infrastructure for hooks and other interfaces with plugins, but I'd like to advocate towards not expecting DynFlags to keep existing in eternity. If we assume a subset of what used to be in DynFlags to be relevant to Plugins, let's collect that in say PluginHooks, but let's keep that interface minimal. And maybe that can be specified to stay stable.

DynFlags is our state kitchensink in GHC, and it is everywhere. The state is threaded through everything and the module is gargantuous. So far there seemed to be broad support in removing this wart.

Cheers,
Moritz

On Fri, Sep 18, 2020 at 5:52 PM Adam Gundry <adam at well-typed.com<mailto:adam at well-typed.com>> wrote:
On 14/09/2020 13:02, Moritz Angermann wrote:
> I believe this to already be broken in HEAD. DynFlags already got quite
> an overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
> offer alternative stable interfaces. Though to be honest, I believe our
> Plugin story is rather poor so far.
>
> Do you happen to know of DynFlagPlugins, Adam?

A few have been mentioned in the thread now. What specifically do you
believe is broken in HEAD regarding DynFlags plugins, and is there an
issue for it? AFAICS the hooks-plugin test which corresponds to the
user's guide text is still there.

I think it is important to retain the ability for plugins to manipulate
both DynFlags and Hooks, whether the latter are separated out of the
former or not. Both have legitimate use cases, and plugins necessarily
involve using unstable interfaces (at least until someone designs a
stable interface). I agree that the current state of plugins/hooks is
somewhat ad-hoc and could do with more effort put into the design (like
much else in the GHC API!) but that doesn't mean we should remove things
that work already.

Slightly tangential note: discussing this with Alp I learned about the
log_action/dump_action/trace_action fields of DynFlags, which also seem
to violate Simon's "We should think of DynFlags as an abstract syntax
tree." And indeed it would be useful for plugins to be able to override
log_action, especially combined with #18516, as then we would have a
nice story for plugins overriding error message generation to allow for
domain-specific error messages.

Cheers,

Adam


> On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <adam at well-typed.com<mailto:adam at well-typed.com>
> <mailto:adam at well-typed.com<mailto:adam at well-typed.com>>> wrote:
>
>     I'm supportive of the goal, but a complication with removing hooks from
>     DynFlags is that GHC currently supports "DynFlags plugins" that allow
>     plugins to install custom hooks
>     (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins<https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_ghc.html%23dynflags-plugins&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258108460&sdata=h6bor7jYE96tW%2BkICk%2BodTG9tbKkS4taiLyFLWmrRJE%3D&reserved=0>).
>     I guess this can be worked around, perhaps by passing hooks separately
>     to DynFlags and providing a separate plugin interface to modify hooks.
>     But doing so will necessarily break existing plugins.
>
>     Adam
>
>
>     On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
>     > I thought I’d sent a message about this DynFlags thing, but I can’t
>     > trace it now.   So here’s a resend.
>     >
>     >
>     >
>     > Currently
>     >
>     >   * The DynFlags record includes Hooks
>     >   * Hooks in contains functions, that mention TcM, DsM etc
>     >
>     >
>     >
>     > This is bad.  We should think of DynFlags as an *abstract syntax
>     tree*.
>     > That is, the result of parsing the flag strings, yes, but not much
>     > more.  So for hooks we should have an algebraic data type representing
>     > the hook /specification/, but it should not be the hook functions
>     > themselves.  HsSyn, for example, after parsing, is just a tree with
>     > strings in it.  No TyCons, Ids, etc. That comes much later.
>     >
>     >
>     >
>     > So DynFlags should be a collection of algebraic data types, but should
>     > not depend on anything else.
>     >
>     >
>     >
>     > I think that may cut a bunch of awkward loops.
>     >
>     >
>     >
>     > Simon
>     >
>     >
>     >
>     > *From:*Simon Peyton Jones
>     > *Sent:* 10 September 2020 14:17
>     > *To:* Sebastian Graf <sgraf1337 at gmail.com<mailto:sgraf1337 at gmail.com>
>     <mailto:sgraf1337 at gmail.com<mailto:sgraf1337 at gmail.com>>>; Sylvain Henry
>     > <sylvain at haskus.fr<mailto:sylvain at haskus.fr> <mailto:sylvain at haskus.fr<mailto:sylvain at haskus.fr>>>
>     > *Cc:* ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>>
>     > *Subject:* RE: Parser depends on DynFlags, depends on Hooks,
>     depends on
>     > TcM, DsM, ...
>     >
>     >
>     >
>     > And for sure the **parser** should not depend on the **desugarer** and
>     > **typechecker**.   (Which it does, as described below.)
>     >
>     >
>     >
>     https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins<https://nam06.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fextending_ghc.html%23dynflags-plugins&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258118424&sdata=umpDUPC3uoHUnPtjah4L8iGnEOacnsFRGr4fT760CGQ%3D&reserved=0>
>     > S
>     >
>     >
>     >
>     > *From:*ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>
>     <mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>>
>     > <mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>
>     <mailto:ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>>>> *On Behalf Of *Sebastian Graf
>     > *Sent:* 10 September 2020 14:12
>     > *To:* Sylvain Henry <sylvain at haskus.fr<mailto:sylvain at haskus.fr> <mailto:sylvain at haskus.fr<mailto:sylvain at haskus.fr>>
>     <mailto:sylvain at haskus.fr<mailto:sylvain at haskus.fr> <mailto:sylvain at haskus.fr<mailto:sylvain at haskus.fr>>>>
>     > *Cc:* ghc-devs <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>
>     <mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>>>>
>     > *Subject:* Parser depends on DynFlags, depends on Hooks, depends
>     on TcM,
>     > DsM, ...
>     >
>     >
>     >
>     > Hey Sylvain,
>     >
>     >
>     >
>     > In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258118424&sdata=2H%2FvZzMZOaoAyFEnvO2LSGpr4gIO4PYHPE6ynWr9eCo%3D&reserved=0>
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258128372&sdata=dACDLVEDLpvpb8WUYmC2DHi%2FJ97d2AKeXRY6eNUMzgY%3D&reserved=0>>
>     > I had to fight once more with the transitive dependency set of the
>     > parser, the minimality of which is crucial for ghc-lib-parser
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258128372&sdata=c%2F68cNhMxm3HmewVAdc5iFaxkUJ4Dds2oCS2S62y2qw%3D&reserved=0>>
>     > and tested by the CountParserDeps test.
>     >
>     >
>     >
>     > I discovered that I need to make (parts of) `DsM` abstract, because it
>     > is transitively imported from the Parser for example through
>     Parser.y ->
>     > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
>     >
>     > Since you are our mastermind behind the "Tame DynFlags"
>     initiative, I'd
>     > like to hear your opinion on where progress can be/is made on that
>     front.
>     >
>     >
>     >
>     > I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258138335&sdata=Qd0gnkQvpAFhjrkHmbU%2FJfhu39IfmRUgfXJbcNGr4UE%3D&reserved=0>
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258138335&sdata=Qd0gnkQvpAFhjrkHmbU%2FJfhu39IfmRUgfXJbcNGr4UE%3D&reserved=0>>
>     > and https://gitlab.haskell.org/ghc/ghc/-/issues/11301<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258148291&sdata=L1ZzCHw4xZF2ZXxvBq8Ucb3cNPwjwGrrbRMXAd4NWKE%3D&reserved=0>
>     >
>     <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258148291&sdata=L1ZzCHw4xZF2ZXxvBq8Ucb3cNPwjwGrrbRMXAd4NWKE%3D&reserved=0>>
>     > which ask a related, but different question: They want a DynFlags-free
>     > interface, but I even want a DynFlags-free *module*.
>     >
>     >
>     >
>     > Would you say it's reasonable to abstract the definition of `PState`
>     > over the `DynFlags` type? I think it's only used for pretty-printing
>     > messages, which is one of your specialties (the treatment of
>     DynFlags in
>     > there, at least).
>     >
>     > Anyway, can you think of or perhaps point me to an existing road
>     map on
>     > that issue?
>     >
>     >
>     >
>     > Thank you!
>     >
>     > Sebastian


--
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.well-typed.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2263056bd1744a04e4b08d85bdaceba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637360344258158247&sdata=jcKsOscvZDaemr6roAP%2BOVow5DrvPD4AYYsPsb%2BD0k8%3D&reserved=0>

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200918/190e75d3/attachment.html>

From adam at well-typed.com  Fri Sep 18 14:17:02 2020
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 18 Sep 2020 15:17:02 +0100
Subject: Parser depends on DynFlags, depends on Hooks, depends on TcM,
 DsM, ...
In-Reply-To: <CAKfdd-zG1KiTMkrnycyXSvhpguHF6rTKswCamGohy_GGcQjJHQ@mail.gmail.com>
References: <CAAS+=P-N7XqBX_tX669ns8CQQ4pAOUi=p8W4hCc8NRo2M3a-VA@mail.gmail.com>
 <VI1PR83MB0429A00A905F8DE461ACFB96AD270@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <VI1PR83MB04298D8F201D51E1F0367153AD230@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <0fe87958-f261-78c7-e200-9caccf515c93@well-typed.com>
 <CAKfdd-xYShVG6g1h+0kfZ5SD_hFrLj4YsBXxFNzOj=JBQCYOQg@mail.gmail.com>
 <e0b7373e-3317-2d00-aaee-ec9566348e9d@well-typed.com>
 <CAKfdd-zG1KiTMkrnycyXSvhpguHF6rTKswCamGohy_GGcQjJHQ@mail.gmail.com>
Message-ID: <acbe0ed2-1f32-94f8-000d-22fcef1668c2@well-typed.com>

Right, we don't want plugins to continue to have access to the *current*
DynFlags, because I agree that needs to be cut down. I certainly
wouldn't retain it as-is just for plugins.

Instead, I'm merely arguing that we should continue to let plugins
modify (a) the command-line-flags-as-AST (which is what I presume
DynFlags should become), and (b) the Hooks (perhaps with one or two
additions, e.g. log_action). Apologies if I caused confusion earlier by
referring to (a) as "DynFlags".

Cheers,

Adam


On 18/09/2020 14:56, Moritz Angermann wrote:
> I'm not certain anything in HEAD actually breaks any plugin today. But
> the whole idea of plugins having full access to what currently is
> "DynFlags" is not something I believe we can sustain. @Sylvain Henry
> <mailto:sylvain at haskus.fr> is currently cleaning up a lot of unnecessary
> DynFlags usage. I'm not against keeping the necessary infrastructure for
> hooks and other interfaces with plugins, but I'd like to advocate
> towards not expecting DynFlags to keep existing in eternity. If we
> assume a subset of what used to be in DynFlags to be relevant to
> Plugins, let's collect that in say PluginHooks, but let's keep that
> interface minimal. And maybe that can be specified to stay stable.
> 
> DynFlags is our state kitchensink in GHC, and it is everywhere. The
> state is threaded through everything and the module is gargantuous. So
> far there seemed to be broad support in removing this wart.
> 
> Cheers, 
> Moritz
> 
> On Fri, Sep 18, 2020 at 5:52 PM Adam Gundry <adam at well-typed.com
> <mailto:adam at well-typed.com>> wrote:
> 
>     On 14/09/2020 13:02, Moritz Angermann wrote:
>     > I believe this to already be broken in HEAD. DynFlags already got
>     quite
>     > an overhaul/break. I'd rather we drop supporting DynFlagPlugins. And
>     > offer alternative stable interfaces. Though to be honest, I
>     believe our
>     > Plugin story is rather poor so far.
>     >
>     > Do you happen to know of DynFlagPlugins, Adam?
> 
>     A few have been mentioned in the thread now. What specifically do you
>     believe is broken in HEAD regarding DynFlags plugins, and is there an
>     issue for it? AFAICS the hooks-plugin test which corresponds to the
>     user's guide text is still there.
> 
>     I think it is important to retain the ability for plugins to manipulate
>     both DynFlags and Hooks, whether the latter are separated out of the
>     former or not. Both have legitimate use cases, and plugins necessarily
>     involve using unstable interfaces (at least until someone designs a
>     stable interface). I agree that the current state of plugins/hooks is
>     somewhat ad-hoc and could do with more effort put into the design (like
>     much else in the GHC API!) but that doesn't mean we should remove things
>     that work already.
> 
>     Slightly tangential note: discussing this with Alp I learned about the
>     log_action/dump_action/trace_action fields of DynFlags, which also seem
>     to violate Simon's "We should think of DynFlags as an abstract syntax
>     tree." And indeed it would be useful for plugins to be able to override
>     log_action, especially combined with #18516, as then we would have a
>     nice story for plugins overriding error message generation to allow for
>     domain-specific error messages.
> 
>     Cheers,
> 
>     Adam
> 
> 
>     > On Mon, Sep 14, 2020 at 7:09 PM Adam Gundry <adam at well-typed.com
>     <mailto:adam at well-typed.com>
>     > <mailto:adam at well-typed.com <mailto:adam at well-typed.com>>> wrote:
>     >
>     >     I'm supportive of the goal, but a complication with removing
>     hooks from
>     >     DynFlags is that GHC currently supports "DynFlags plugins"
>     that allow
>     >     plugins to install custom hooks
>     >   
>      (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins).
>     >     I guess this can be worked around, perhaps by passing hooks
>     separately
>     >     to DynFlags and providing a separate plugin interface to
>     modify hooks.
>     >     But doing so will necessarily break existing plugins.
>     >
>     >     Adam
>     >
>     >
>     >     On 14/09/2020 11:25, Simon Peyton Jones via ghc-devs wrote:
>     >     > I thought I’d sent a message about this DynFlags thing, but
>     I can’t
>     >     > trace it now.   So here’s a resend.
>     >     >
>     >     >  
>     >     >
>     >     > Currently
>     >     >
>     >     >   * The DynFlags record includes Hooks
>     >     >   * Hooks in contains functions, that mention TcM, DsM etc
>     >     >
>     >     >  
>     >     >
>     >     > This is bad.  We should think of DynFlags as an *abstract syntax
>     >     tree*. 
>     >     > That is, the result of parsing the flag strings, yes, but
>     not much
>     >     > more.  So for hooks we should have an algebraic data type
>     representing
>     >     > the hook /specification/, but it should not be the hook
>     functions
>     >     > themselves.  HsSyn, for example, after parsing, is just a
>     tree with
>     >     > strings in it.  No TyCons, Ids, etc. That comes much later.
>     >     >
>     >     >  
>     >     >
>     >     > So DynFlags should be a collection of algebraic data types,
>     but should
>     >     > not depend on anything else.
>     >     >
>     >     >  
>     >     >
>     >     > I think that may cut a bunch of awkward loops.
>     >     >
>     >     >  
>     >     >
>     >     > Simon
>     >     >
>     >     >  
>     >     >
>     >     > *From:*Simon Peyton Jones
>     >     > *Sent:* 10 September 2020 14:17
>     >     > *To:* Sebastian Graf <sgraf1337 at gmail.com
>     <mailto:sgraf1337 at gmail.com>
>     >     <mailto:sgraf1337 at gmail.com <mailto:sgraf1337 at gmail.com>>>;
>     Sylvain Henry
>     >     > <sylvain at haskus.fr <mailto:sylvain at haskus.fr>
>     <mailto:sylvain at haskus.fr <mailto:sylvain at haskus.fr>>>
>     >     > *Cc:* ghc-devs <ghc-devs at haskell.org
>     <mailto:ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org
>     <mailto:ghc-devs at haskell.org>>>
>     >     > *Subject:* RE: Parser depends on DynFlags, depends on Hooks,
>     >     depends on
>     >     > TcM, DsM, ...
>     >     >
>     >     >  
>     >     >
>     >     > And for sure the **parser** should not depend on the
>     **desugarer** and
>     >     > **typechecker**.   (Which it does, as described below.)
>     >     >
>     >     >  
>     >     >
>     >   
>      https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending_ghc.html#dynflags-plugins
>     >     > S
>     >     >
>     >     >  
>     >     >
>     >     > *From:*ghc-devs <ghc-devs-bounces at haskell.org
>     <mailto:ghc-devs-bounces at haskell.org>
>     >     <mailto:ghc-devs-bounces at haskell.org
>     <mailto:ghc-devs-bounces at haskell.org>>
>     >     > <mailto:ghc-devs-bounces at haskell.org
>     <mailto:ghc-devs-bounces at haskell.org>
>     >     <mailto:ghc-devs-bounces at haskell.org
>     <mailto:ghc-devs-bounces at haskell.org>>>> *On Behalf Of *Sebastian Graf
>     >     > *Sent:* 10 September 2020 14:12
>     >     > *To:* Sylvain Henry <sylvain at haskus.fr
>     <mailto:sylvain at haskus.fr> <mailto:sylvain at haskus.fr
>     <mailto:sylvain at haskus.fr>>
>     >     <mailto:sylvain at haskus.fr <mailto:sylvain at haskus.fr>
>     <mailto:sylvain at haskus.fr <mailto:sylvain at haskus.fr>>>>
>     >     > *Cc:* ghc-devs <ghc-devs at haskell.org
>     <mailto:ghc-devs at haskell.org> <mailto:ghc-devs at haskell.org
>     <mailto:ghc-devs at haskell.org>>
>     >     <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     <mailto:ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>>>>
>     >     > *Subject:* Parser depends on DynFlags, depends on Hooks, depends
>     >     on TcM,
>     >     > DsM, ...
>     >     >
>     >     >  
>     >     >
>     >     > Hey Sylvain,
>     >     >
>     >     >  
>     >     >
>     >     > In https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3971
>     >     >
>     >   
>      <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F3971&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753453548&sdata=fVpIzJgaqFfWaJ5ppCE5daHwdETTQF03o1h0uNtDxGA%3D&reserved=0>
>     >     > I had to fight once more with the transitive dependency set
>     of the
>     >     > parser, the minimality of which is crucial for ghc-lib-parser
>     >     >
>     >   
>      <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-lib-parser&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=HZMaqK6t7PLifc26wf%2BqcUef4Ko%2BQcaPRx4o7XLcVq8%3D&reserved=0>
>     >     > and tested by the CountParserDeps test.
>     >     >
>     >     >  
>     >     >
>     >     > I discovered that I need to make (parts of) `DsM` abstract,
>     because it
>     >     > is transitively imported from the Parser for example through
>     >     Parser.y ->
>     >     > Lexer.x -> DynFlags -> Hooks -> {DsM,TcM}.
>     >     >
>     >     > Since you are our mastermind behind the "Tame DynFlags"
>     >     initiative, I'd
>     >     > like to hear your opinion on where progress can be/is made
>     on that
>     >     front.
>     >     >
>     >     >  
>     >     >
>     >     > I see there is https://gitlab.haskell.org/ghc/ghc/-/issues/10961
>     >     >
>     >   
>      <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F10961&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=sn9zv1MO8p%2FSbwsm1NDaSiUaumE%2FvTo4NkGreYOjITA%3D&reserved=0>
>     >     > and https://gitlab.haskell.org/ghc/ghc/-/issues/11301
>     >     >
>     >   
>      <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F11301&data=02%7C01%7Csimonpj%40microsoft.com%7C0c3760e72fad4200d39408d8558b3871%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637353404753463506&sdata=vFTEuEzIQLJTtpu7%2BuwFnOEWMPv8eY%2B%2FvgbrrV18uss%3D&reserved=0>
>     >     > which ask a related, but different question: They want a
>     DynFlags-free
>     >     > interface, but I even want a DynFlags-free *module*.
>     >     >
>     >     >  
>     >     >
>     >     > Would you say it's reasonable to abstract the definition of
>     `PState`
>     >     > over the `DynFlags` type? I think it's only used for
>     pretty-printing
>     >     > messages, which is one of your specialties (the treatment of
>     >     DynFlags in
>     >     > there, at least).
>     >     >
>     >     > Anyway, can you think of or perhaps point me to an existing road
>     >     map on
>     >     > that issue?
>     >     >
>     >     >  
>     >     >
>     >     > Thank you!
>     >     >
>     >     > Sebastian


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
118 Wymering Mansions, Wymering Road, London W9 2NF, England

From b.gohla at gmx.de  Tue Sep 22 23:28:18 2020
From: b.gohla at gmx.de (=?us-ascii?Q?=3D=3Futf-8=3FQ=3FBj=3DC3=3DB6rn=5FGohla=3F=3D?=)
Date: Wed, 23 Sep 2020 00:28:18 +0100
Subject: GHC 8.10.2 build error: missing .cfi_startproc
Message-ID: <871rit1je5.fsf@titanic.my.domain>

Hello,

I'm trying to build ghc-8.10.2 on OpenBSD 6.7, the build finally fails
with an error message from the assembler:


     ===--- building phase 0
     gmake --no-print-directory -f ghc.mk phase=0 phase_0_builds
     gmake[1]: Nothing to be done for 'phase_0_builds'.
     ===--- building phase 1
     gmake --no-print-directory -f ghc.mk phase=1 phase_1_builds
     gmake[1]: Nothing to be done for 'phase_1_builds'.
     ===--- building final phase
     gmake --no-print-directory -f ghc.mk phase=final all
     "inplace/bin/ghc-stage1" -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-w -static  -O0 -H64m -Wall  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen            -O2 -Wcpp-undef   -Wnoncanonical-monad-instances  -c rts/StgCRun.c -o rts/dist/build/StgCRun.o
     rts/StgCRun.c: Assembler messages:

     rts/StgCRun.c:382:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     382 |         "movq %%rbx,0(%%rax)\n\t"
         | ^

     rts/StgCRun.c:383:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     383 |         "movq %%rbp,8(%%rax)\n\t"
         | ^

     rts/StgCRun.c:384:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     384 |         "movq %%r12,16(%%rax)\n\t"
         | ^

     rts/StgCRun.c:385:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     385 |         "movq %%r13,24(%%rax)\n\t"
         | ^

     rts/StgCRun.c:386:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     386 |         "movq %%r14,32(%%rax)\n\t"
         | ^

     rts/StgCRun.c:387:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     387 |         "movq %%r15,40(%%rax)\n\t"
         | ^

     rts/StgCRun.c:388:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     388 | #if defined(mingw32_HOST_OS)
         | ^

     rts/StgCRun.c:389:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     389 |         /*
         | ^

     rts/StgCRun.c:390:0: error:
          Error: CFI instruction used without previous .cfi_startproc
         |
     390 |          * Additional callee saved registers on Win64. This must match
         | ^
     `egcc' failed in phase `Assembler'. (Exit code: 1)
     gmake[1]: *** [rts/ghc.mk:322: rts/dist/build/StgCRun.o] Error 1
     gmake: *** [Makefile:128: all] Error 2

Looking in the source file rts/StgCRun.c and reading the GNU assembler
manual concerning CFI directives, it seems to me that in the function
StgRunIsImplementedInAssembler starting on line 368 the assembler block
should perhaps have started with .cfi_startproc and ended with
.cfi_endproc .

Although I suspect it's perhaps a question of telling GCC not to expect
those directives.

I'm using gcc-8.3.0 and ghc-8.6.4 to compile.

I would be grateful for any insight anyone might have to offer.

--
Kindly,
Björn Gohla

From simonpj at microsoft.com  Thu Sep 24 18:21:46 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 24 Sep 2020 18:21:46 +0000
Subject: Quick Look has landed
Message-ID: <VI1PR83MB04291733A560138703257912AD390@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Dimitrios, Jurriaan, Alejandro
I'm happy to tell you that Quick Look has landed on GHC's master branch.
It'll be in GHC 9.2, but is usable already by building HEAD.  Good work!
The implementation is very faithful to the paper, which was an invaluable guide.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200924/9ee6554c/attachment.html>

From trupill at gmail.com  Fri Sep 25 13:07:41 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Fri, 25 Sep 2020 15:07:41 +0200
Subject: Quick Look has landed
In-Reply-To: <CALeLSB+49Acw==D2PTJ8gD0i8WgZ_3CB8u28=7VbGoW+GDs1LA@mail.gmail.com>
References: <VI1PR83MB04291733A560138703257912AD390@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CALeLSB+49Acw==D2PTJ8gD0i8WgZ_3CB8u28=7VbGoW+GDs1LA@mail.gmail.com>
Message-ID: <CAHnFXOtPjha4CgK5Qps6KkTHVrdO06P=RJ20o67w3--9bmGtJQ@mail.gmail.com>

Awesome news! Thanks so much, Simon, for all the programming effort you've
put into this :)

Alejandro

El jue., 24 sept. 2020 a las 22:04, Dimitrios Vytiniotis (<
dimitriv at gmail.com>) escribió:

> Wow this is great news!!! We finally landed something acceptable after 15
> years.... Thanks so much for all the hard work on the implementation side
> Alejandro and Simon.
>
> On Thu, 24 Sep 2020, 21:21 Simon Peyton Jones, <simonpj at microsoft.com>
> wrote:
>
>> Dimitrios, Jurriaan, Alejandro
>>
>> I’m happy to tell you that Quick Look has landed on GHC’s master branch.
>>
>> It’ll be in GHC 9.2, but is usable already by building HEAD.  Good work!
>>
>> The implementation is very faithful to the paper, which was an invaluable
>> guide.
>>
>> Simon
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200925/e7401268/attachment.html>

From ryan.gl.scott at gmail.com  Fri Sep 25 22:21:23 2020
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Fri, 25 Sep 2020 18:21:23 -0400
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
Message-ID: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>

GHC imposes an upper bound of 62 on the size of tuples one can use [1].
Currently, this upper bound applies to both boxed and unboxed tuples alike.
For example, if you try to create an unboxed tuple of arity 64, then GHC
will throw an error:

    error:
        A 64-tuple is too large for GHC
          (max size is 62)
          Workaround: use nested tuples or define a data type
      |
      | f =
(#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,#)
      |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

However, I discovered recently that there are places where GHC *does* use
unboxed tuples with arity greater than 62. For example, the
GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size 64. I
was confused for a while about how this was even possible, but I realized
later than GHC only enforces the tuple size limit in expressions and
patterns [3]. Simply having a type signature with a large unboxed tuple is
fine in and of itself, and since unpackInt8X64# is implemented as a primop,
no large unboxed tuples are ever used in the "body" of the function.
(Indeed, primops don't have function bodies in the conventional sense.)
Other functions in GHC.Prim that use unboxed tuples of arity 64 include
unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].

But this makes me wonder: how on earth is it even possible to *use*
unpackInt8X64#? The only thing that comes to mind is to pattern-match on
the unboxed tuple that it returns, but if you try to do that, you'll get a
"64-tuple is too large for GHC" error like shown above. What's more, I
can't find any test cases in the GHC test suite that show how
unpackInt8X64# or its cousins are supposed to be used. What am I missing?
The comments for these functions mention "Warning: this is only available
on LLVM", so perhaps someone familiar with the LLVM backend knows what the
answer is?

For some context, this came up in !4097, where I am attempting to extend
the "too large for GHC" error message to include types, in addition to
expressions and patterns [7]. However, doing so causes Haddock to error
when processing unpackInt8X64# et al.

Ryan S.
-----
[1]
https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/compiler/GHC/Settings/Constants.hs#L13-15
[2]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackInt8X64-35-
[3] https://gitlab.haskell.org/ghc/ghc/-/issues/18723
[4]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackWord8X64-35-
[5]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packInt8X64-35-
[6]
https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packWord8X64-35-
[7] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4097#note_301191
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200925/7ac6f4d8/attachment.html>

From moritz.angermann at gmail.com  Sat Sep 26 09:43:01 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 26 Sep 2020 17:43:01 +0800
Subject: Native Code Generator for AArch64
Message-ID: <CAKfdd-z0nPoM3BKZeKPLnGsjA1eksob-UG1qndCLtKr_+VsGsw@mail.gmail.com>

Hi there!

As some may know I've been working on a native code generation backend for
aarch64[1].  When Ben initially wrote about The state of GHC on ARM[2], I
was quite skeptical if a native code generator would really be what we
should be doing.  And the claim it would take a week or two, might have
been underestimating the complexity a bit; but also the time needed to
debug crashing programs.

The idea of a NCG however intrigued me.  I did work on an alternative llvm
backend once, so I did know a bit about the code gen backend.  I also knew
a bit about aarch64 assembly from working on the rts linker for aarch64.

So here we are today, with an aarch64 ncg for ghc[3], that has some basic
optimizations included, but does not beat the llvm codegen yet in runtime
performance. It is however substantially faster than the llvm codegen for
compile time performance.

I have performed nofib benchmarks for:
- full llvm build vs full native build[4]
- llvm nofib, with native libraries, vs full native build[5]
to discriminate effects of compiling just the nofib programs vs. the impact
the libraries have.

I've only had time to take a cursory look over the generated assembly for
the CSD test, and the llvm codegen seems to be able to produce quite
different assembly, thus there seem to be some good optimizations llvm
manages to exploit. I'll have to investigate this closer and probably look
at the llvm IR we generate and the intermediate optimization steps llvm
manages to apply to it, as the llvm assembly doesn't ressemble the ncg
assembly much.

I plan to look at aarch64/mach-o and performance over the coming weeks.

I hope we can get this in for 9.2.

Cheers,
 Moritz

--
[1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
[2]: https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
[3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
[4]: https://gist.github.com/9d93454b832b769b5bdb4e731a10c068
[5]: https://gist.github.com/acc4dab7836f1f509716ac398a94d949
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200926/0ce72922/attachment.html>

From ben at smart-cactus.org  Sat Sep 26 11:53:59 2020
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 26 Sep 2020 07:53:59 -0400
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
Message-ID: <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>

On September 25, 2020 6:21:23 PM EDT, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
...
>However, I discovered recently that there are places where GHC *does*
>use
>unboxed tuples with arity greater than 62. For example, the
>GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size
>64. I
>was confused for a while about how this was even possible, but I
>realized
>later than GHC only enforces the tuple size limit in expressions and
>patterns [3]. Simply having a type signature with a large unboxed tuple
>is
>fine in and of itself, and since unpackInt8X64# is implemented as a
>primop,
>no large unboxed tuples are ever used in the "body" of the function.
>(Indeed, primops don't have function bodies in the conventional sense.)
>Other functions in GHC.Prim that use unboxed tuples of arity 64 include
>unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
>
>But this makes me wonder: how on earth is it even possible to *use*
>unpackInt8X64#? 


I strongly suspect that the answer here is "you can't yet no one has noticed until now." The SIMD operations were essentially introduced as a technology preview and therefore never had proper tests added. Only a subset of these operations have any tests at all and I doubt anyone has attempted to use the 64-wide operations, which are rather specialized.

Cheers,

- Ben 

From ryan.gl.scott at gmail.com  Sat Sep 26 12:26:32 2020
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Sat, 26 Sep 2020 08:26:32 -0400
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
 <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>
Message-ID: <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>

I had a feeling that this might be the case. Unfortunately, this technology
preview is actively blocking progress on !4097, which leaves me at a loss
for what to do. I can see two ways forward:

1. Remove unpackInt8X64# and friends.
2. Reconsider whether the tuple size limit should apply to unboxed tuples.
Perhaps this size limit only makes sense for boxed tuples? This comment [1]
suggests that defining a boxed tuple of size greater than 62 induces a
segfault, but it's unclear to me if the same thing happens for unboxed
tuples.

Ryan S.
-----
[1]
https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170

On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben at smart-cactus.org> wrote:

> On September 25, 2020 6:21:23 PM EDT, Ryan Scott <ryan.gl.scott at gmail.com>
> wrote:
> ...
> >However, I discovered recently that there are places where GHC *does*
> >use
> >unboxed tuples with arity greater than 62. For example, the
> >GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size
> >64. I
> >was confused for a while about how this was even possible, but I
> >realized
> >later than GHC only enforces the tuple size limit in expressions and
> >patterns [3]. Simply having a type signature with a large unboxed tuple
> >is
> >fine in and of itself, and since unpackInt8X64# is implemented as a
> >primop,
> >no large unboxed tuples are ever used in the "body" of the function.
> >(Indeed, primops don't have function bodies in the conventional sense.)
> >Other functions in GHC.Prim that use unboxed tuples of arity 64 include
> >unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
> >
> >But this makes me wonder: how on earth is it even possible to *use*
> >unpackInt8X64#?
>
>
> I strongly suspect that the answer here is "you can't yet no one has
> noticed until now." The SIMD operations were essentially introduced as a
> technology preview and therefore never had proper tests added. Only a
> subset of these operations have any tests at all and I doubt anyone has
> attempted to use the 64-wide operations, which are rather specialized.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200926/a072748c/attachment.html>

From moritz.angermann at gmail.com  Sat Sep 26 12:39:28 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 26 Sep 2020 20:39:28 +0800
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
 <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>
 <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
Message-ID: <CAKfdd-zo4NDsCx=1HN3dCu43Fr-4NFkZJ4_UzGjebt3BVy9rig@mail.gmail.com>

Luite is currently working on unboxed tuple support in the interpreter.
This will also be limited, as getting a generic solution for arbitrary
sized tuples raises a lot of complications.

Thus form a practical point of view, I’d go for (1) ;-)

We’ll need to rethink and get SIMD proper support at some point though, the
lack of such is rather sad.

On Sat, 26 Sep 2020 at 8:27 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> I had a feeling that this might be the case. Unfortunately, this
> technology preview is actively blocking progress on
>
> !4097, which leaves me at a loss for what to do. I can see two ways
> forward:
>
> 1. Remove
>
> unpackInt8X64#
>
>
>
> and friends.
> 2. Reconsider whether the tuple size limit should apply to unboxed tuples.
> Perhaps this size limit only makes sense for boxed tuples? This comment [1]
> suggests that defining a boxed tuple of size greater than 62 induces a
> segfault, but it's unclear to me if the same thing happens for unboxed
> tuples.
>
> Ryan S.
> -----
> [1]
> https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170
>
>
>
>
> On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben at smart-cactus.org> wrote:
>
>> On September 25, 2020 6:21:23 PM EDT, Ryan Scott <ryan.gl.scott at gmail.com>
>> wrote:
>>
>>
>> ...
>>
>>
>> >However, I discovered recently that there are places where GHC *does*
>>
>>
>> >use
>>
>>
>> >unboxed tuples with arity greater than 62. For example, the
>>
>>
>> >GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size
>>
>>
>> >64. I
>>
>>
>> >was confused for a while about how this was even possible, but I
>>
>>
>> >realized
>>
>>
>> >later than GHC only enforces the tuple size limit in expressions and
>>
>>
>> >patterns [3]. Simply having a type signature with a large unboxed tuple
>>
>>
>> >is
>>
>>
>> >fine in and of itself, and since unpackInt8X64# is implemented as a
>>
>>
>> >primop,
>>
>>
>> >no large unboxed tuples are ever used in the "body" of the function.
>>
>>
>> >(Indeed, primops don't have function bodies in the conventional sense.)
>>
>>
>> >Other functions in GHC.Prim that use unboxed tuples of arity 64 include
>>
>>
>> >unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
>>
>>
>> >
>>
>>
>> >But this makes me wonder: how on earth is it even possible to *use*
>>
>>
>> >unpackInt8X64#?
>>
>>
>>
>>
>>
>>
>>
>>
>> I strongly suspect that the answer here is "you can't yet no one has
>> noticed until now." The SIMD operations were essentially introduced as a
>> technology preview and therefore never had proper tests added. Only a
>> subset of these operations have any tests at all and I doubt anyone has
>> attempted to use the 64-wide operations, which are rather specialized.
>>
>>
>>
>>
>>
>> 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/20200926/42f54812/attachment.html>

From ben at well-typed.com  Sat Sep 26 12:52:00 2020
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 26 Sep 2020 08:52:00 -0400
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
 <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>
 <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
Message-ID: <B365A345-850C-4F94-AF47-A458CA6AF551@well-typed.com>

I think it would be worth trying to add tuples up to width 64. The only real cost here is the interface file size of GHC.Tuple and if adding a 63-wide tuple really does induce a crash then that is a bug in its own right that deserves investigation. 

- Ben 

On September 26, 2020 8:26:32 AM EDT, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>I had a feeling that this might be the case. Unfortunately, this
>technology
>preview is actively blocking progress on !4097, which leaves me at a
>loss
>for what to do. I can see two ways forward:
>
>1. Remove unpackInt8X64# and friends.
>2. Reconsider whether the tuple size limit should apply to unboxed
>tuples.
>Perhaps this size limit only makes sense for boxed tuples? This comment
>[1]
>suggests that defining a boxed tuple of size greater than 62 induces a
>segfault, but it's unclear to me if the same thing happens for unboxed
>tuples.
>
>Ryan S.
>-----
>[1]
>https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170
>
>On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben at smart-cactus.org>
>wrote:
>
>> On September 25, 2020 6:21:23 PM EDT, Ryan Scott
><ryan.gl.scott at gmail.com>
>> wrote:
>> ...
>> >However, I discovered recently that there are places where GHC
>*does*
>> >use
>> >unboxed tuples with arity greater than 62. For example, the
>> >GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of
>size
>> >64. I
>> >was confused for a while about how this was even possible, but I
>> >realized
>> >later than GHC only enforces the tuple size limit in expressions and
>> >patterns [3]. Simply having a type signature with a large unboxed
>tuple
>> >is
>> >fine in and of itself, and since unpackInt8X64# is implemented as a
>> >primop,
>> >no large unboxed tuples are ever used in the "body" of the function.
>> >(Indeed, primops don't have function bodies in the conventional
>sense.)
>> >Other functions in GHC.Prim that use unboxed tuples of arity 64
>include
>> >unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
>> >
>> >But this makes me wonder: how on earth is it even possible to *use*
>> >unpackInt8X64#?
>>
>>
>> I strongly suspect that the answer here is "you can't yet no one has
>> noticed until now." The SIMD operations were essentially introduced
>as a
>> technology preview and therefore never had proper tests added. Only a
>> subset of these operations have any tests at all and I doubt anyone
>has
>> attempted to use the 64-wide operations, which are rather
>specialized.
>>
>> Cheers,
>>
>> - Ben
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200926/411ebcd5/attachment.html>

From moritz.angermann at gmail.com  Sat Sep 26 13:11:26 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 26 Sep 2020 21:11:26 +0800
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <B365A345-850C-4F94-AF47-A458CA6AF551@well-typed.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
 <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>
 <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
 <B365A345-850C-4F94-AF47-A458CA6AF551@well-typed.com>
Message-ID: <CAKfdd-yo9BHs4bfH1iVhzBURZuk=YX05Je0naowwNu2Op3HSdw@mail.gmail.com>

I think as long as it's bounded it's ok.

On Sat, Sep 26, 2020 at 8:52 PM Ben Gamari <ben at well-typed.com> wrote:

> I think it would be worth trying to add tuples up to width 64. The only
> real cost here is the interface file size of GHC.Tuple and if adding a
> 63-wide tuple really does induce a crash then that is a bug in its own
> right that deserves investigation.
>
> - Ben
>
> On September 26, 2020 8:26:32 AM EDT, Ryan Scott <ryan.gl.scott at gmail.com>
> wrote:
>>
>> I had a feeling that this might be the case. Unfortunately, this
>> technology preview is actively blocking progress on !4097, which leaves me
>> at a loss for what to do. I can see two ways forward:
>>
>> 1. Remove unpackInt8X64# and friends.
>> 2. Reconsider whether the tuple size limit should apply to unboxed
>> tuples. Perhaps this size limit only makes sense for boxed tuples? This
>> comment [1] suggests that defining a boxed tuple of size greater than 62
>> induces a segfault, but it's unclear to me if the same thing happens for
>> unboxed tuples.
>>
>> Ryan S.
>> -----
>> [1]
>> https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170
>>
>> On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben at smart-cactus.org> wrote:
>>
>>> On September 25, 2020 6:21:23 PM EDT, Ryan Scott <
>>> ryan.gl.scott at gmail.com> wrote:
>>> ...
>>> >However, I discovered recently that there are places where GHC *does*
>>> >use
>>> >unboxed tuples with arity greater than 62. For example, the
>>> >GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size
>>> >64. I
>>> >was confused for a while about how this was even possible, but I
>>> >realized
>>> >later than GHC only enforces the tuple size limit in expressions and
>>> >patterns [3]. Simply having a type signature with a large unboxed tuple
>>> >is
>>> >fine in and of itself, and since unpackInt8X64# is implemented as a
>>> >primop,
>>> >no large unboxed tuples are ever used in the "body" of the function.
>>> >(Indeed, primops don't have function bodies in the conventional sense.)
>>> >Other functions in GHC.Prim that use unboxed tuples of arity 64 include
>>> >unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
>>> >
>>> >But this makes me wonder: how on earth is it even possible to *use*
>>> >unpackInt8X64#?
>>>
>>>
>>> I strongly suspect that the answer here is "you can't yet no one has
>>> noticed until now." The SIMD operations were essentially introduced as a
>>> technology preview and therefore never had proper tests added. Only a
>>> subset of these operations have any tests at all and I doubt anyone has
>>> attempted to use the 64-wide operations, which are rather specialized.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> 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/20200926/f3e98ea4/attachment.html>

From takenobu.hs at gmail.com  Sun Sep 27 01:57:03 2020
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Sun, 27 Sep 2020 10:57:03 +0900
Subject: Native Code Generator for AArch64
In-Reply-To: <CAKfdd-z0nPoM3BKZeKPLnGsjA1eksob-UG1qndCLtKr_+VsGsw@mail.gmail.com>
References: <CAKfdd-z0nPoM3BKZeKPLnGsjA1eksob-UG1qndCLtKr_+VsGsw@mail.gmail.com>
Message-ID: <CAPB_NvwnDvPsaaZG2PSGTGgMeuBrkUnAEbPXws-LC2jQi64OBA@mail.gmail.com>

Steady and wonderful work!


Regards,
Takenobu

On Sat, Sep 26, 2020 at 6:44 PM Moritz Angermann
<moritz.angermann at gmail.com> wrote:
>
> Hi there!
>
> As some may know I've been working on a native code generation backend for aarch64[1].  When Ben initially wrote about The state of GHC on ARM[2], I was quite skeptical if a native code generator would really be what we should be doing.  And the claim it would take a week or two, might have been underestimating the complexity a bit; but also the time needed to debug crashing programs.
>
> The idea of a NCG however intrigued me.  I did work on an alternative llvm backend once, so I did know a bit about the code gen backend.  I also knew a bit about aarch64 assembly from working on the rts linker for aarch64.
>
> So here we are today, with an aarch64 ncg for ghc[3], that has some basic optimizations included, but does not beat the llvm codegen yet in runtime performance. It is however substantially faster than the llvm codegen for compile time performance.
>
> I have performed nofib benchmarks for:
> - full llvm build vs full native build[4]
> - llvm nofib, with native libraries, vs full native build[5]
> to discriminate effects of compiling just the nofib programs vs. the impact the libraries have.
>
> I've only had time to take a cursory look over the generated assembly for the CSD test, and the llvm codegen seems to be able to produce quite different assembly, thus there seem to be some good optimizations llvm manages to exploit. I'll have to investigate this closer and probably look at the llvm IR we generate and the intermediate optimization steps llvm manages to apply to it, as the llvm assembly doesn't ressemble the ncg assembly much.
>
> I plan to look at aarch64/mach-o and performance over the coming weeks.
>
> I hope we can get this in for 9.2.
>
> Cheers,
>  Moritz
>
> --
> [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
> [2]: https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
> [3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
> [4]: https://gist.github.com/9d93454b832b769b5bdb4e731a10c068
> [5]: https://gist.github.com/acc4dab7836f1f509716ac398a94d949
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From mail at vilem.net  Sun Sep 27 11:04:25 2020
From: mail at vilem.net (=?UTF-8?Q?Vilem_Liepelt?=)
Date: Sun, 27 Sep 2020 11:04:25 +0000
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com> 
 <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org> 
 <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com> 
 <77F5FA7A-F22D-48E4-B68B-F27392D3D1B5@vilem.net>
Message-ID: <01020174cf3c3d35-b947adc0-e04f-4e79-a1aa-e3232d8a5cd4-000000@eu-west-1.amazonses.com>

Ryan, the comment in GHC.Tuple seems to be misleading today, as suggested by this SO post: https://stackoverflow.com/questions/46412823/why-are-ghc-tuples-limited-to-size-62

I was going to add it to the comment at some point but was hesitant as I hadn’t verified the information myself.

V

On 26 Sep 2020, at 14:26, Ryan Scott <ryan.gl.scott at gmail.com <mailto:ryan.gl.scott at gmail.com> > wrote:

I had a feeling that this might be the case. Unfortunately, this technology preview is actively blocking progress on !4097, which leaves me at a loss for what to do. I can see two ways forward:

1. Remove unpackInt8X64# and friends.
2. Reconsider whether the tuple size limit should apply to unboxed tuples. Perhaps this size limit only makes sense for boxed tuples? This comment [1] suggests that defining a boxed tuple of size greater than 62 induces a segfault, but it's unclear to me if the same thing happens for unboxed tuples.

Ryan S.
-----
[1] https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170

On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben at smart-cactus.org <mailto:ben at smart-cactus.org> > wrote:
On September 25, 2020 6:21:23 PM EDT, Ryan Scott <ryan.gl.scott at gmail.com <mailto:ryan.gl.scott at gmail.com> > wrote:
...
>However, I discovered recently that there are places where GHC *does*
>use
>unboxed tuples with arity greater than 62. For example, the
>GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size
>64. I
>was confused for a while about how this was even possible, but I
>realized
>later than GHC only enforces the tuple size limit in expressions and
>patterns [3]. Simply having a type signature with a large unboxed tuple

>is
>fine in and of itself, and since unpackInt8X64# is implemented as a
>primop,
>no large unboxed tuples are ever used in the "body" of the function.
>(Indeed, primops don't have function bodies in the conventional sense.)

>Other functions in GHC.Prim that use unboxed tuples of arity 64 include

>unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
>
>But this makes me wonder: how on earth is it even possible to *use*
>unpackInt8X64#? 


I strongly suspect that the answer here is "you can't yet no one has noticed until now." The SIMD operations were essentially introduced as a technology preview and therefore never had proper tests added. Only a subset of these operations have any tests at all and I doubt anyone has attempted to use the 64-wide operations, which are rather specialized.

Cheers,

- Ben 
_______________________________________________
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200927/b68248a0/attachment.html>

From shayne.fletcher.50 at gmail.com  Sun Sep 27 13:47:13 2020
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Sun, 27 Sep 2020 09:47:13 -0400
Subject: Native Code Generator for AArch64
In-Reply-To: <CAKfdd-z0nPoM3BKZeKPLnGsjA1eksob-UG1qndCLtKr_+VsGsw@mail.gmail.com>
References: <CAKfdd-z0nPoM3BKZeKPLnGsjA1eksob-UG1qndCLtKr_+VsGsw@mail.gmail.com>
Message-ID: <CAMsAzy9N4k38zJcuQ3K2K3=pCEewH30hqNUTvYPJhoaqJ9GWKQ@mail.gmail.com>

Outstanding!

On Sat, Sep 26, 2020, 05:43 Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Hi there!
>
> As some may know I've been working on a native code generation backend for
> aarch64[1].  When Ben initially wrote about The state of GHC on ARM[2], I
> was quite skeptical if a native code generator would really be what we
> should be doing.  And the claim it would take a week or two, might have
> been underestimating the complexity a bit; but also the time needed to
> debug crashing programs.
>
> The idea of a NCG however intrigued me.  I did work on an alternative llvm
> backend once, so I did know a bit about the code gen backend.  I also knew
> a bit about aarch64 assembly from working on the rts linker for aarch64.
>
> So here we are today, with an aarch64 ncg for ghc[3], that has some basic
> optimizations included, but does not beat the llvm codegen yet in runtime
> performance. It is however substantially faster than the llvm codegen for
> compile time performance.
>
> I have performed nofib benchmarks for:
> - full llvm build vs full native build[4]
> - llvm nofib, with native libraries, vs full native build[5]
> to discriminate effects of compiling just the nofib programs vs. the
> impact the libraries have.
>
> I've only had time to take a cursory look over the generated assembly for
> the CSD test, and the llvm codegen seems to be able to produce quite
> different assembly, thus there seem to be some good optimizations llvm
> manages to exploit. I'll have to investigate this closer and probably look
> at the llvm IR we generate and the intermediate optimization steps llvm
> manages to apply to it, as the llvm assembly doesn't ressemble the ncg
> assembly much.
>
> I plan to look at aarch64/mach-o and performance over the coming weeks.
>
> I hope we can get this in for 9.2.
>
> Cheers,
>  Moritz
>
> --
> [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
> [2]: https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html
> [3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641
> [4]: https://gist.github.com/9d93454b832b769b5bdb4e731a10c068
> [5]: https://gist.github.com/acc4dab7836f1f509716ac398a94d949
> _______________________________________________
> 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/20200927/1fffde21/attachment.html>

From stegeman at gmail.com  Mon Sep 28 08:33:59 2020
From: stegeman at gmail.com (Luite Stegeman)
Date: Mon, 28 Sep 2020 10:33:59 +0200
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <CAKfdd-zo4NDsCx=1HN3dCu43Fr-4NFkZJ4_UzGjebt3BVy9rig@mail.gmail.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
 <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>
 <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
 <CAKfdd-zo4NDsCx=1HN3dCu43Fr-4NFkZJ4_UzGjebt3BVy9rig@mail.gmail.com>
Message-ID: <CALqQuoj-mLo+RTR-nOeCMfqVmNDbiHvd68AaZYrH781rBWoeew@mail.gmail.com>

The complication for arbitrary sized unboxed tuples in the interpreter
was mainly because we don't want to generate new Cmm on the fly for
each tuple size. That one probably doesn't apply here, but maybe
others do.

It looks like a fully general solution would require a change to the
calling convention, which required more changes than I hoped. For now
it there will be a limitation in tuple size; the number of words
passed on the stack in the native calling convention:
https://gitlab.haskell.org/luite/ghc/-/commit/f83d08f0247bd7fd590b9be450c6d2d0968caa3c#6ca006a5d6dfdfdb97d0dd72db322e3f6eaa6214_198_217

It's probably not a big problem if GHCi has some size limit here, even
if GHC doesn't (or has a higher limit)

Bumping tuple size limits a bit to make the primops usable (testable?)
looks okay to me.

Luite

On Sat, Sep 26, 2020 at 2:39 PM Moritz Angermann
<moritz.angermann at gmail.com> wrote:
>
> Luite is currently working on unboxed tuple support in the interpreter. This will also be limited, as getting a generic solution for arbitrary sized tuples raises a lot of complications.
>
> Thus form a practical point of view, I’d go for (1) ;-)
>
> We’ll need to rethink and get SIMD proper support at some point though, the lack of such is rather sad.
>
> On Sat, 26 Sep 2020 at 8:27 PM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>>
>> I had a feeling that this might be the case. Unfortunately, this technology preview is actively blocking progress on
>>
>> !4097, which leaves me at a loss for what to do. I can see two ways forward:
>>
>> 1. Remove
>>
>> unpackInt8X64#
>>
>>
>>
>> and friends.
>> 2. Reconsider whether the tuple size limit should apply to unboxed tuples. Perhaps this size limit only makes sense for boxed tuples? This comment [1] suggests that defining a boxed tuple of size greater than 62 induces a segfault, but it's unclear to me if the same thing happens for unboxed tuples.
>>
>> Ryan S.
>> -----
>> [1] https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/libraries/ghc-prim/GHC/Tuple.hs#L170
>>
>>
>>
>>
>> On Sat, Sep 26, 2020 at 7:54 AM Ben Gamari <ben at smart-cactus.org> wrote:
>>>
>>> On September 25, 2020 6:21:23 PM EDT, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
>>>
>>>
>>> ...
>>>
>>>
>>> >However, I discovered recently that there are places where GHC *does*
>>>
>>>
>>> >use
>>>
>>>
>>> >unboxed tuples with arity greater than 62. For example, the
>>>
>>>
>>> >GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size
>>>
>>>
>>> >64. I
>>>
>>>
>>> >was confused for a while about how this was even possible, but I
>>>
>>>
>>> >realized
>>>
>>>
>>> >later than GHC only enforces the tuple size limit in expressions and
>>>
>>>
>>> >patterns [3]. Simply having a type signature with a large unboxed tuple
>>>
>>>
>>> >is
>>>
>>>
>>> >fine in and of itself, and since unpackInt8X64# is implemented as a
>>>
>>>
>>> >primop,
>>>
>>>
>>> >no large unboxed tuples are ever used in the "body" of the function.
>>>
>>>
>>> >(Indeed, primops don't have function bodies in the conventional sense.)
>>>
>>>
>>> >Other functions in GHC.Prim that use unboxed tuples of arity 64 include
>>>
>>>
>>> >unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].
>>>
>>>
>>> >
>>>
>>>
>>> >But this makes me wonder: how on earth is it even possible to *use*
>>>
>>>
>>> >unpackInt8X64#?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I strongly suspect that the answer here is "you can't yet no one has noticed until now." The SIMD operations were essentially introduced as a technology preview and therefore never had proper tests added. Only a subset of these operations have any tests at all and I doubt anyone has attempted to use the 64-wide operations, which are rather specialized.
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>>
>>> - Ben
>>>
>>>
>>
>>
>> _______________________________________________
>>
>> ghc-devs mailing list
>>
>> ghc-devs at haskell.org
>>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>

From simonpj at microsoft.com  Mon Sep 28 09:02:53 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 28 Sep 2020 09:02:53 +0000
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
Message-ID: <VI1PR83MB042953EDFF12771E16518FEAAD350@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Hmm.   It’s not clear to me why we have *any* limitation on the size of unboxed tuples.

For boxed tuples I know: we need an info table, code etc. But not so for unboxed.

Why do we need a limit at all?

Simon

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ryan Scott
Sent: 25 September 2020 23:21
To: GHC developers <ghc-devs at haskell.org>
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?

GHC imposes an upper bound of 62 on the size of tuples one can use [1]. Currently, this upper bound applies to both boxed and unboxed tuples alike. For example, if you try to create an unboxed tuple of arity 64, then GHC will throw an error:

    error:
        A 64-tuple is too large for GHC
          (max size is 62)
          Workaround: use nested tuples or define a data type
      |
      | f = (#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,#)
      |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

However, I discovered recently that there are places where GHC *does* use unboxed tuples with arity greater than 62. For example, the GHC.Prim.unpackInt8X64# [2] function returns an unboxed tuple of size 64. I was confused for a while about how this was even possible, but I realized later than GHC only enforces the tuple size limit in expressions and patterns [3]. Simply having a type signature with a large unboxed tuple is fine in and of itself, and since unpackInt8X64# is implemented as a primop, no large unboxed tuples are ever used in the "body" of the function. (Indeed, primops don't have function bodies in the conventional sense.) Other functions in GHC.Prim that use unboxed tuples of arity 64 include unpackWord8X64# [4], packInt8X64# [5], and packWord8X64# [6].

But this makes me wonder: how on earth is it even possible to *use* unpackInt8X64#? The only thing that comes to mind is to pattern-match on the unboxed tuple that it returns, but if you try to do that, you'll get a "64-tuple is too large for GHC" error like shown above. What's more, I can't find any test cases in the GHC test suite that show how unpackInt8X64# or its cousins are supposed to be used. What am I missing? The comments for these functions mention "Warning: this is only available on LLVM", so perhaps someone familiar with the LLVM backend knows what the answer is?

For some context, this came up in !4097, where I am attempting to extend the "too large for GHC" error message to include types, in addition to expressions and patterns [7]. However, doing so causes Haddock to error when processing unpackInt8X64# et al.

Ryan S.
-----
[1] https://gitlab.haskell.org/ghc/ghc/-/blob/a1f34d37b47826e86343e368a5c00f1a4b1f2bce/compiler/GHC/Settings/Constants.hs#L13-15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fblob%2Fa1f34d37b47826e86343e368a5c00f1a4b1f2bce%2Fcompiler%2FGHC%2FSettings%2FConstants.hs%23L13-15&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218050286&sdata=LAb06t4YCkyQgSfp3si07unb0sEW3vE7pEHRbzUxKZU%3D&reserved=0>
[2] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackInt8X64-35-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3AunpackInt8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218060277&sdata=eC52wb5dTfzVVAgJLMc428av%2FDgY9NyqyMCROfkD6ro%3D&reserved=0>
[3] https://gitlab.haskell.org/ghc/ghc/-/issues/18723<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F18723&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218070276&sdata=VRucYwSTbGD1iD9KhJst2ZTmsuZ%2BQdwKTyivnTqKBm4%3D&reserved=0>
[4] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:unpackWord8X64-35-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3AunpackWord8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218070276&sdata=3naSYWb5y2SpznOO0y4ip9Pd3hzzmbSuBWViCPbM%2FAU%3D&reserved=0>
[5] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packInt8X64-35-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3ApackInt8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218080272&sdata=QpdcjMe1gN91NJAPzTjdksFFXR3sibl5bZqhd23f6Hc%3D&reserved=0>
[6] https://hackage.haskell.org/package/ghc-prim-0.6.1/docs/GHC-Prim.html#v:packWord8X64-35-<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhackage.haskell.org%2Fpackage%2Fghc-prim-0.6.1%2Fdocs%2FGHC-Prim.html%23v%3ApackWord8X64-35-&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218090268&sdata=x9%2FqCgRRALtH4%2B7wTK9hqxk%2FrhIqSs%2BPwIk%2BjQlljsY%3D&reserved=0>
[7] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4097#note_301191<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F4097%23note_301191&data=02%7C01%7Csimonpj%40microsoft.com%7Ca2fa232c729f4943412a08d861a170e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637366699218090268&sdata=oGUSsN7bwBLV9p7MchpSfQH4dtjWm6apaumIM1IGg2Q%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200928/47f6124c/attachment.html>

From ryan.gl.scott at gmail.com  Mon Sep 28 09:57:03 2020
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 28 Sep 2020 05:57:03 -0400
Subject: How is GHC.Prim.unpackInt8X64# meant to be used?
In-Reply-To: <01020174cf3c3d35-b947adc0-e04f-4e79-a1aa-e3232d8a5cd4-000000@eu-west-1.amazonses.com>
References: <CADdQpRB7_XD-AhGihTVoUjNmW+X6QaE-83=Aoeq_Ft-==Hh99Q@mail.gmail.com>
 <5F03703C-E2E2-4C55-80ED-923E04A56297@smart-cactus.org>
 <77F5FA7A-F22D-48E4-B68B-F27392D3D1B5@vilem.net>
 <CADdQpRBDEPJoJMYLQjm2c6gD_bQMW5WKygBVjMGrWX0_qw7mBg@mail.gmail.com>
 <01020174cf3c3d35-b947adc0-e04f-4e79-a1aa-e3232d8a5cd4-000000@eu-west-1.amazonses.com>
Message-ID: <CADdQpRAMD6etBH=RiA8qOUSxoBNQjGZnA+zqe_vr8PR6TQ_=og@mail.gmail.com>

 > Ryan, the comment in GHC.Tuple seems to be misleading today, as
suggested by this SO post:
https://stackoverflow.com/questions/46412823/why-are-ghc-tuples-limited-to-size-62

> I was going to add it to the comment at some point but was hesitant as I
hadn’t verified the information myself.

For what it's worth, Ben has removed this comment in !4146 [1], where he
increases the maximum tuple size to 64. This is enough to unblock me on
progressing with !4097, so I'm happy. There seems to be a more general
question of whether it makes sense to enforce a size limit at all for
unboxed tuples, but I'll leave that question to people more knowledgeable
than I am.

Ryan S.
-----
[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4146
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200928/a2208691/attachment.html>

From ben at well-typed.com  Mon Sep 28 19:14:04 2020
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 28 Sep 2020 15:14:04 -0400
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
Message-ID: <873631g1e2.fsf@smart-cactus.org>

Hello all,

The GHC team is very pleased to announce the availability of the first
alpha release in the GHC 9.0 series. Source and binary distributions are
available at the usual place:

    https://downloads.haskell.org/ghc/9.0.1-alpha1/

This first alpha comes quite a bit later than expected. However, we have
done a significant amount of testing on this pre-release and therefore
hope to be able to move forward quickly with a release candidate next
week and with a final release in mid-October.

GHC 9.0.1 will bring a number of new features:

 * A first cut of the new LinearTypes language extension [1], 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 [2]
   simplifying the type system and paving the way for QuickLook
   impredicativity in GHC 9.2.

 * Implementation of the QualifiedDo extension [3], allowing more
   convenient overloading of `do` syntax.

 * Improvements in compilation time.

And many more. See the release notes [4] for a full accounting of the
changes in this release.

Do note that there are a few things that we expect will change before
the final release:

 * We expect to sort out a notarization workflow for Apple Darwin,
   allowing our binary distributions to be used on macOS Catalina
   without hassle.

   Until this has been sorted out Catalina users can exempt the
   current macOS binary distribution from the notarization requirement
   themselves by running `xattr -cr .` on the unpacked tree before
   running `make install`.

 * We will likely transition the Alpine binary distribution to be fully
   statically-linked, providing a convenient, distribution-independent
   packaging option for Linux users.

 * We will be merging a robust solution for #17760 which will introduce
   a new primitive, `keepAlive#`, to the `base` library, subsuming
   most uses of `touch#`.

As always, do test this release and open tickets for whatever issues you
encounter. To help with this, we will be publishing a blog post
describing use of our new `head.hackage` infrastructure to ease testing
of larger projects with Hackage dependencies later this week.

Cheers,

- Ben


[1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
[2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
[3] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst 
[4] https://downloads.haskell.org/ghc/9.0.1-alpha1/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/20200928/c19c4dd4/attachment.sig>

From cheng.shao at tweag.io  Tue Sep 29 10:53:58 2020
From: cheng.shao at tweag.io (Cheng Shao)
Date: Tue, 29 Sep 2020 12:53:58 +0200
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: <CALHrtFm8L5gbhTqOiym9MEUtpKJG8SZktFgxW7FeJ0QNk-Pirg@mail.gmail.com>

Hi Ben,

> We will likely transition the Alpine binary distribution to be fully
   statically-linked, providing a convenient, distribution-independent
   packaging option for Linux users.

iirc for statically linked executables, musl doesn't even support
dlopen, so wouldn't this mean such a bindist would fail for all
LoadDLL ghci commands?

Cheers,
Cheng

On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <ben at well-typed.com> wrote:
>
> Hello all,
>
> The GHC team is very pleased to announce the availability of the first
> alpha release in the GHC 9.0 series. Source and binary distributions are
> available at the usual place:
>
>     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>
> This first alpha comes quite a bit later than expected. However, we have
> done a significant amount of testing on this pre-release and therefore
> hope to be able to move forward quickly with a release candidate next
> week and with a final release in mid-October.
>
> GHC 9.0.1 will bring a number of new features:
>
>  * A first cut of the new LinearTypes language extension [1], 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 [2]
>    simplifying the type system and paving the way for QuickLook
>    impredicativity in GHC 9.2.
>
>  * Implementation of the QualifiedDo extension [3], allowing more
>    convenient overloading of `do` syntax.
>
>  * Improvements in compilation time.
>
> And many more. See the release notes [4] for a full accounting of the
> changes in this release.
>
> Do note that there are a few things that we expect will change before
> the final release:
>
>  * We expect to sort out a notarization workflow for Apple Darwin,
>    allowing our binary distributions to be used on macOS Catalina
>    without hassle.
>
>    Until this has been sorted out Catalina users can exempt the
>    current macOS binary distribution from the notarization requirement
>    themselves by running `xattr -cr .` on the unpacked tree before
>    running `make install`.
>
>  * We will likely transition the Alpine binary distribution to be fully
>    statically-linked, providing a convenient, distribution-independent
>    packaging option for Linux users.
>
>  * We will be merging a robust solution for #17760 which will introduce
>    a new primitive, `keepAlive#`, to the `base` library, subsuming
>    most uses of `touch#`.
>
> As always, do test this release and open tickets for whatever issues you
> encounter. To help with this, we will be publishing a blog post
> describing use of our new `head.hackage` infrastructure to ease testing
> of larger projects with Hackage dependencies later this week.
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
> [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
> [3] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
> [4] https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From moritz.angermann at gmail.com  Tue Sep 29 11:04:02 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 29 Sep 2020 19:04:02 +0800
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
In-Reply-To: <CALHrtFm8L5gbhTqOiym9MEUtpKJG8SZktFgxW7FeJ0QNk-Pirg@mail.gmail.com>
References: <873631g1e2.fsf@smart-cactus.org>
 <CALHrtFm8L5gbhTqOiym9MEUtpKJG8SZktFgxW7FeJ0QNk-Pirg@mail.gmail.com>
Message-ID: <CAKfdd-xzeygYjhCcEC-ynj4zr1nz1EsBdVDtCocLNfE4oXG=0g@mail.gmail.com>

No. Not necessarily. We can perfectly fine load archives and the pre-linked
ghci objects. However dlopen with musl on x86 seems fine. On arm it’s not
implemented, and just throws an error message. There is a -dynamic flag in
HEAD, which disables GHC even trying to load dynamic libraries and always
assuming there is no dynamic linking facility, even if configure reports
the existence of dlopen...

On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao <cheng.shao at tweag.io> wrote:

> Hi Ben,
>
>
>
> > We will likely transition the Alpine binary distribution to be fully
>
>    statically-linked, providing a convenient, distribution-independent
>
>    packaging option for Linux users.
>
>
>
> iirc for statically linked executables, musl doesn't even support
>
> dlopen, so wouldn't this mean such a bindist would fail for all
>
> LoadDLL ghci commands?
>
>
>
> Cheers,
>
> Cheng
>
>
>
> On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <ben at well-typed.com> wrote:
>
> >
>
> > Hello all,
>
> >
>
> > The GHC team is very pleased to announce the availability of the first
>
> > alpha release in the GHC 9.0 series. Source and binary distributions are
>
> > available at the usual place:
>
> >
>
> >     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>
> >
>
> > This first alpha comes quite a bit later than expected. However, we have
>
> > done a significant amount of testing on this pre-release and therefore
>
> > hope to be able to move forward quickly with a release candidate next
>
> > week and with a final release in mid-October.
>
> >
>
> > GHC 9.0.1 will bring a number of new features:
>
> >
>
> >  * A first cut of the new LinearTypes language extension [1], 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 [2]
>
> >    simplifying the type system and paving the way for QuickLook
>
> >    impredicativity in GHC 9.2.
>
> >
>
> >  * Implementation of the QualifiedDo extension [3], allowing more
>
> >    convenient overloading of `do` syntax.
>
> >
>
> >  * Improvements in compilation time.
>
> >
>
> > And many more. See the release notes [4] for a full accounting of the
>
> > changes in this release.
>
> >
>
> > Do note that there are a few things that we expect will change before
>
> > the final release:
>
> >
>
> >  * We expect to sort out a notarization workflow for Apple Darwin,
>
> >    allowing our binary distributions to be used on macOS Catalina
>
> >    without hassle.
>
> >
>
> >    Until this has been sorted out Catalina users can exempt the
>
> >    current macOS binary distribution from the notarization requirement
>
> >    themselves by running `xattr -cr .` on the unpacked tree before
>
> >    running `make install`.
>
> >
>
> >  * We will likely transition the Alpine binary distribution to be fully
>
> >    statically-linked, providing a convenient, distribution-independent
>
> >    packaging option for Linux users.
>
> >
>
> >  * We will be merging a robust solution for #17760 which will introduce
>
> >    a new primitive, `keepAlive#`, to the `base` library, subsuming
>
> >    most uses of `touch#`.
>
> >
>
> > As always, do test this release and open tickets for whatever issues you
>
> > encounter. To help with this, we will be publishing a blog post
>
> > describing use of our new `head.hackage` infrastructure to ease testing
>
> > of larger projects with Hackage dependencies later this week.
>
> >
>
> > Cheers,
>
> >
>
> > - Ben
>
> >
>
> >
>
> > [1]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
>
> > [2]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
>
> > [3]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
>
> > [4]
> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
>
> > _______________________________________________
>
> > 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/20200929/fb4aef16/attachment.html>

From cheng.shao at tweag.io  Tue Sep 29 11:18:26 2020
From: cheng.shao at tweag.io (Cheng Shao)
Date: Tue, 29 Sep 2020 13:18:26 +0200
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
In-Reply-To: <CAKfdd-xzeygYjhCcEC-ynj4zr1nz1EsBdVDtCocLNfE4oXG=0g@mail.gmail.com>
References: <873631g1e2.fsf@smart-cactus.org>
 <CALHrtFm8L5gbhTqOiym9MEUtpKJG8SZktFgxW7FeJ0QNk-Pirg@mail.gmail.com>
 <CAKfdd-xzeygYjhCcEC-ynj4zr1nz1EsBdVDtCocLNfE4oXG=0g@mail.gmail.com>
Message-ID: <CALHrtFk=cRiPeYn76AcjdDohxaHBpq5HK-A7uxo3t9=fBosnzw@mail.gmail.com>

Hi Moritz,

> However dlopen with musl on x86 seems fine.

Here's a dlopen example that segfaults if linked with -static:

#include <stdio.h>
#include <dlfcn.h>

int main() {
  void *h = dlopen("/usr/lib/libsqlite3.so", RTLD_NOW);
  char *f = dlsym(h, "sqlite3_version");
  printf("%s\n", f);
  return 0;
}

On Tue, Sep 29, 2020 at 1:04 PM Moritz Angermann
<moritz.angermann at gmail.com> wrote:
>
> No. Not necessarily. We can perfectly fine load archives and the pre-linked ghci objects. However dlopen with musl on x86 seems fine. On arm it’s not implemented, and just throws an error message. There is a -dynamic flag in HEAD, which disables GHC even trying to load dynamic libraries and always assuming there is no dynamic linking facility, even if configure reports the existence of dlopen...
>
> On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>>
>> Hi Ben,
>>
>>
>>
>> > We will likely transition the Alpine binary distribution to be fully
>>
>>    statically-linked, providing a convenient, distribution-independent
>>
>>    packaging option for Linux users.
>>
>>
>>
>> iirc for statically linked executables, musl doesn't even support
>>
>> dlopen, so wouldn't this mean such a bindist would fail for all
>>
>> LoadDLL ghci commands?
>>
>>
>>
>> Cheers,
>>
>> Cheng
>>
>>
>>
>> On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>> >
>>
>> > Hello all,
>>
>> >
>>
>> > The GHC team is very pleased to announce the availability of the first
>>
>> > alpha release in the GHC 9.0 series. Source and binary distributions are
>>
>> > available at the usual place:
>>
>> >
>>
>> >     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>>
>> >
>>
>> > This first alpha comes quite a bit later than expected. However, we have
>>
>> > done a significant amount of testing on this pre-release and therefore
>>
>> > hope to be able to move forward quickly with a release candidate next
>>
>> > week and with a final release in mid-October.
>>
>> >
>>
>> > GHC 9.0.1 will bring a number of new features:
>>
>> >
>>
>> >  * A first cut of the new LinearTypes language extension [1], 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 [2]
>>
>> >    simplifying the type system and paving the way for QuickLook
>>
>> >    impredicativity in GHC 9.2.
>>
>> >
>>
>> >  * Implementation of the QualifiedDo extension [3], allowing more
>>
>> >    convenient overloading of `do` syntax.
>>
>> >
>>
>> >  * Improvements in compilation time.
>>
>> >
>>
>> > And many more. See the release notes [4] for a full accounting of the
>>
>> > changes in this release.
>>
>> >
>>
>> > Do note that there are a few things that we expect will change before
>>
>> > the final release:
>>
>> >
>>
>> >  * We expect to sort out a notarization workflow for Apple Darwin,
>>
>> >    allowing our binary distributions to be used on macOS Catalina
>>
>> >    without hassle.
>>
>> >
>>
>> >    Until this has been sorted out Catalina users can exempt the
>>
>> >    current macOS binary distribution from the notarization requirement
>>
>> >    themselves by running `xattr -cr .` on the unpacked tree before
>>
>> >    running `make install`.
>>
>> >
>>
>> >  * We will likely transition the Alpine binary distribution to be fully
>>
>> >    statically-linked, providing a convenient, distribution-independent
>>
>> >    packaging option for Linux users.
>>
>> >
>>
>> >  * We will be merging a robust solution for #17760 which will introduce
>>
>> >    a new primitive, `keepAlive#`, to the `base` library, subsuming
>>
>> >    most uses of `touch#`.
>>
>> >
>>
>> > As always, do test this release and open tickets for whatever issues you
>>
>> > encounter. To help with this, we will be publishing a blog post
>>
>> > describing use of our new `head.hackage` infrastructure to ease testing
>>
>> > of larger projects with Hackage dependencies later this week.
>>
>> >
>>
>> > Cheers,
>>
>> >
>>
>> > - Ben
>>
>> >
>>
>> >
>>
>> > [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
>>
>> > [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
>>
>> > [3] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
>>
>> > [4] https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
>>
>> > _______________________________________________
>>
>> > 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 moritz.angermann at gmail.com  Tue Sep 29 11:45:05 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 29 Sep 2020 19:45:05 +0800
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
In-Reply-To: <CALHrtFk=cRiPeYn76AcjdDohxaHBpq5HK-A7uxo3t9=fBosnzw@mail.gmail.com>
References: <873631g1e2.fsf@smart-cactus.org>
 <CALHrtFm8L5gbhTqOiym9MEUtpKJG8SZktFgxW7FeJ0QNk-Pirg@mail.gmail.com>
 <CAKfdd-xzeygYjhCcEC-ynj4zr1nz1EsBdVDtCocLNfE4oXG=0g@mail.gmail.com>
 <CALHrtFk=cRiPeYn76AcjdDohxaHBpq5HK-A7uxo3t9=fBosnzw@mail.gmail.com>
Message-ID: <CAKfdd-zrDHXan0B7Uq1M1CDViUVm-c7fF4qE-itkfjZGK21NHw@mail.gmail.com>

Happy to give this a try later today. Been using fully static musl builds
(including cross compilation) for x86_64 for a while now; and did not
(yet?) run into that SQLite issue. But did have it use shared objects in
iserv.

On Tue, 29 Sep 2020 at 7:18 PM, Cheng Shao <cheng.shao at tweag.io> wrote:

> Hi Moritz,
>
>
>
> > However dlopen with musl on x86 seems fine.
>
>
>
> Here's a dlopen example that segfaults if linked with -static:
>
>
>
> #include <stdio.h>
>
> #include <dlfcn.h>
>
>
>
> int main() {
>
>   void *h = dlopen("/usr/lib/libsqlite3.so", RTLD_NOW);
>
>   char *f = dlsym(h, "sqlite3_version");
>
>   printf("%s\n", f);
>
>   return 0;
>
> }
>
>
>
> On Tue, Sep 29, 2020 at 1:04 PM Moritz Angermann
>
> <moritz.angermann at gmail.com> wrote:
>
> >
>
> > No. Not necessarily. We can perfectly fine load archives and the
> pre-linked ghci objects. However dlopen with musl on x86 seems fine. On arm
> it’s not implemented, and just throws an error message. There is a -dynamic
> flag in HEAD, which disables GHC even trying to load dynamic libraries and
> always assuming there is no dynamic linking facility, even if configure
> reports the existence of dlopen...
>
> >
>
> > On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>
> >>
>
> >> Hi Ben,
>
> >>
>
> >>
>
> >>
>
> >> > We will likely transition the Alpine binary distribution to be fully
>
> >>
>
> >>    statically-linked, providing a convenient, distribution-independent
>
> >>
>
> >>    packaging option for Linux users.
>
> >>
>
> >>
>
> >>
>
> >> iirc for statically linked executables, musl doesn't even support
>
> >>
>
> >> dlopen, so wouldn't this mean such a bindist would fail for all
>
> >>
>
> >> LoadDLL ghci commands?
>
> >>
>
> >>
>
> >>
>
> >> Cheers,
>
> >>
>
> >> Cheng
>
> >>
>
> >>
>
> >>
>
> >> On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <ben at well-typed.com> wrote:
>
> >>
>
> >> >
>
> >>
>
> >> > Hello all,
>
> >>
>
> >> >
>
> >>
>
> >> > The GHC team is very pleased to announce the availability of the first
>
> >>
>
> >> > alpha release in the GHC 9.0 series. Source and binary distributions
> are
>
> >>
>
> >> > available at the usual place:
>
> >>
>
> >> >
>
> >>
>
> >> >     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>
> >>
>
> >> >
>
> >>
>
> >> > This first alpha comes quite a bit later than expected. However, we
> have
>
> >>
>
> >> > done a significant amount of testing on this pre-release and therefore
>
> >>
>
> >> > hope to be able to move forward quickly with a release candidate next
>
> >>
>
> >> > week and with a final release in mid-October.
>
> >>
>
> >> >
>
> >>
>
> >> > GHC 9.0.1 will bring a number of new features:
>
> >>
>
> >> >
>
> >>
>
> >> >  * A first cut of the new LinearTypes language extension [1], 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 [2]
>
> >>
>
> >> >    simplifying the type system and paving the way for QuickLook
>
> >>
>
> >> >    impredicativity in GHC 9.2.
>
> >>
>
> >> >
>
> >>
>
> >> >  * Implementation of the QualifiedDo extension [3], allowing more
>
> >>
>
> >> >    convenient overloading of `do` syntax.
>
> >>
>
> >> >
>
> >>
>
> >> >  * Improvements in compilation time.
>
> >>
>
> >> >
>
> >>
>
> >> > And many more. See the release notes [4] for a full accounting of the
>
> >>
>
> >> > changes in this release.
>
> >>
>
> >> >
>
> >>
>
> >> > Do note that there are a few things that we expect will change before
>
> >>
>
> >> > the final release:
>
> >>
>
> >> >
>
> >>
>
> >> >  * We expect to sort out a notarization workflow for Apple Darwin,
>
> >>
>
> >> >    allowing our binary distributions to be used on macOS Catalina
>
> >>
>
> >> >    without hassle.
>
> >>
>
> >> >
>
> >>
>
> >> >    Until this has been sorted out Catalina users can exempt the
>
> >>
>
> >> >    current macOS binary distribution from the notarization requirement
>
> >>
>
> >> >    themselves by running `xattr -cr .` on the unpacked tree before
>
> >>
>
> >> >    running `make install`.
>
> >>
>
> >> >
>
> >>
>
> >> >  * We will likely transition the Alpine binary distribution to be
> fully
>
> >>
>
> >> >    statically-linked, providing a convenient, distribution-independent
>
> >>
>
> >> >    packaging option for Linux users.
>
> >>
>
> >> >
>
> >>
>
> >> >  * We will be merging a robust solution for #17760 which will
> introduce
>
> >>
>
> >> >    a new primitive, `keepAlive#`, to the `base` library, subsuming
>
> >>
>
> >> >    most uses of `touch#`.
>
> >>
>
> >> >
>
> >>
>
> >> > As always, do test this release and open tickets for whatever issues
> you
>
> >>
>
> >> > encounter. To help with this, we will be publishing a blog post
>
> >>
>
> >> > describing use of our new `head.hackage` infrastructure to ease
> testing
>
> >>
>
> >> > of larger projects with Hackage dependencies later this week.
>
> >>
>
> >> >
>
> >>
>
> >> > Cheers,
>
> >>
>
> >> >
>
> >>
>
> >> > - Ben
>
> >>
>
> >> >
>
> >>
>
> >> >
>
> >>
>
> >> > [1]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
>
> >>
>
> >> > [2]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
>
> >>
>
> >> > [3]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
>
> >>
>
> >> > [4]
> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
>
> >>
>
> >> > _______________________________________________
>
> >>
>
> >> > 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/20200929/e83b2330/attachment.html>

From moritz.angermann at gmail.com  Tue Sep 29 14:21:18 2020
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 29 Sep 2020 22:21:18 +0800
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
In-Reply-To: <CAKfdd-zrDHXan0B7Uq1M1CDViUVm-c7fF4qE-itkfjZGK21NHw@mail.gmail.com>
References: <873631g1e2.fsf@smart-cactus.org>
 <CALHrtFm8L5gbhTqOiym9MEUtpKJG8SZktFgxW7FeJ0QNk-Pirg@mail.gmail.com>
 <CAKfdd-xzeygYjhCcEC-ynj4zr1nz1EsBdVDtCocLNfE4oXG=0g@mail.gmail.com>
 <CALHrtFk=cRiPeYn76AcjdDohxaHBpq5HK-A7uxo3t9=fBosnzw@mail.gmail.com>
 <CAKfdd-zrDHXan0B7Uq1M1CDViUVm-c7fF4qE-itkfjZGK21NHw@mail.gmail.com>
Message-ID: <CAKfdd-z7aqkQ-2kiHY7N3F+7fM4673=g+YBQp1152gEtvJbkoQ@mail.gmail.com>

This sent me down an interesting path.  You are right that dlopen on
returns NULL with musl on x86_64, and dlerror will subsequently produce
"Dynamic loading not supported" if asked to compile with -static.  I think
GHC has code to fallback to archives in the case where loading
shared objects fails, but I can't find the code right now.  It still means
you'd need to have static sqlite (in this case) and other libraries around.

I'm still a bit puzzled, and I think I'm missing something.  It remains,
that I know we have musl (x86_64, aarch64) based ghcs in production.  I
wonder if there is something we got right by accident, that makes this work
smoothly for us.  Warrants more investigation.

Cheers,
 Moritz

On Tue, Sep 29, 2020 at 7:45 PM Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Happy to give this a try later today. Been using fully static musl builds
> (including cross compilation) for x86_64 for a while now; and did not
> (yet?) run into that SQLite issue. But did have it use shared objects in
> iserv.
>
> On Tue, 29 Sep 2020 at 7:18 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>
>> Hi Moritz,
>>
>>
>>
>> > However dlopen with musl on x86 seems fine.
>>
>>
>>
>> Here's a dlopen example that segfaults if linked with -static:
>>
>>
>>
>> #include <stdio.h>
>>
>> #include <dlfcn.h>
>>
>>
>>
>> int main() {
>>
>>   void *h = dlopen("/usr/lib/libsqlite3.so", RTLD_NOW);
>>
>>   char *f = dlsym(h, "sqlite3_version");
>>
>>   printf("%s\n", f);
>>
>>   return 0;
>>
>> }
>>
>>
>>
>> On Tue, Sep 29, 2020 at 1:04 PM Moritz Angermann
>>
>> <moritz.angermann at gmail.com> wrote:
>>
>> >
>>
>> > No. Not necessarily. We can perfectly fine load archives and the
>> pre-linked ghci objects. However dlopen with musl on x86 seems fine. On arm
>> it’s not implemented, and just throws an error message. There is a -dynamic
>> flag in HEAD, which disables GHC even trying to load dynamic libraries and
>> always assuming there is no dynamic linking facility, even if configure
>> reports the existence of dlopen...
>>
>> >
>>
>> > On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>>
>> >>
>>
>> >> Hi Ben,
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> > We will likely transition the Alpine binary distribution to be fully
>>
>> >>
>>
>> >>    statically-linked, providing a convenient, distribution-independent
>>
>> >>
>>
>> >>    packaging option for Linux users.
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> iirc for statically linked executables, musl doesn't even support
>>
>> >>
>>
>> >> dlopen, so wouldn't this mean such a bindist would fail for all
>>
>> >>
>>
>> >> LoadDLL ghci commands?
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Cheers,
>>
>> >>
>>
>> >> Cheng
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Hello all,
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > The GHC team is very pleased to announce the availability of the
>> first
>>
>> >>
>>
>> >> > alpha release in the GHC 9.0 series. Source and binary distributions
>> are
>>
>> >>
>>
>> >> > available at the usual place:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > This first alpha comes quite a bit later than expected. However, we
>> have
>>
>> >>
>>
>> >> > done a significant amount of testing on this pre-release and
>> therefore
>>
>> >>
>>
>> >> > hope to be able to move forward quickly with a release candidate next
>>
>> >>
>>
>> >> > week and with a final release in mid-October.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > GHC 9.0.1 will bring a number of new features:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * A first cut of the new LinearTypes language extension [1],
>> 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 [2]
>>
>> >>
>>
>> >> >    simplifying the type system and paving the way for QuickLook
>>
>> >>
>>
>> >> >    impredicativity in GHC 9.2.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * Implementation of the QualifiedDo extension [3], allowing more
>>
>> >>
>>
>> >> >    convenient overloading of `do` syntax.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * Improvements in compilation time.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > And many more. See the release notes [4] for a full accounting of the
>>
>> >>
>>
>> >> > changes in this release.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Do note that there are a few things that we expect will change before
>>
>> >>
>>
>> >> > the final release:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * We expect to sort out a notarization workflow for Apple Darwin,
>>
>> >>
>>
>> >> >    allowing our binary distributions to be used on macOS Catalina
>>
>> >>
>>
>> >> >    without hassle.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >    Until this has been sorted out Catalina users can exempt the
>>
>> >>
>>
>> >> >    current macOS binary distribution from the notarization
>> requirement
>>
>> >>
>>
>> >> >    themselves by running `xattr -cr .` on the unpacked tree before
>>
>> >>
>>
>> >> >    running `make install`.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * We will likely transition the Alpine binary distribution to be
>> fully
>>
>> >>
>>
>> >> >    statically-linked, providing a convenient,
>> distribution-independent
>>
>> >>
>>
>> >> >    packaging option for Linux users.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >  * We will be merging a robust solution for #17760 which will
>> introduce
>>
>> >>
>>
>> >> >    a new primitive, `keepAlive#`, to the `base` library, subsuming
>>
>> >>
>>
>> >> >    most uses of `touch#`.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > As always, do test this release and open tickets for whatever issues
>> you
>>
>> >>
>>
>> >> > encounter. To help with this, we will be publishing a blog post
>>
>> >>
>>
>> >> > describing use of our new `head.hackage` infrastructure to ease
>> testing
>>
>> >>
>>
>> >> > of larger projects with Hackage dependencies later this week.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Cheers,
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > - Ben
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > [1]
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
>>
>> >>
>>
>> >> > [2]
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
>>
>> >>
>>
>> >> > [3]
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
>>
>> >>
>>
>> >> > [4]
>> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
>>
>> >>
>>
>> >> > _______________________________________________
>>
>> >>
>>
>> >> > 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/20200929/3b36f5f2/attachment.html>

From cheng.shao at tweag.io  Tue Sep 29 14:25:34 2020
From: cheng.shao at tweag.io (Cheng Shao)
Date: Tue, 29 Sep 2020 16:25:34 +0200
Subject: [ANNOUNCE] Glasgow Haskell Compiler 9.0.1-alpha1 released
In-Reply-To: <CAKfdd-z7aqkQ-2kiHY7N3F+7fM4673=g+YBQp1152gEtvJbkoQ@mail.gmail.com>
References: <873631g1e2.fsf@smart-cactus.org>
 <CALHrtFm8L5gbhTqOiym9MEUtpKJG8SZktFgxW7FeJ0QNk-Pirg@mail.gmail.com>
 <CAKfdd-xzeygYjhCcEC-ynj4zr1nz1EsBdVDtCocLNfE4oXG=0g@mail.gmail.com>
 <CALHrtFk=cRiPeYn76AcjdDohxaHBpq5HK-A7uxo3t9=fBosnzw@mail.gmail.com>
 <CAKfdd-zrDHXan0B7Uq1M1CDViUVm-c7fF4qE-itkfjZGK21NHw@mail.gmail.com>
 <CAKfdd-z7aqkQ-2kiHY7N3F+7fM4673=g+YBQp1152gEtvJbkoQ@mail.gmail.com>
Message-ID: <CALHrtF=m6c6CDvxYRcBhWwO_K6SwByHUt_auAhTHxMTaPgTj9A@mail.gmail.com>

> that I know we have musl (x86_64, aarch64) based ghcs in production.

These ghc bindists (at least the one produced on gitlab ci) have
dynamically linked ghc executables iirc. Last time I tried to turn off
DYNAMIC_GHC_PROGRAM when building ghc on alpine, the produced ghc will
panic on TH code. That's on the 8.8 branch though.

On Tue, Sep 29, 2020 at 4:21 PM Moritz Angermann
<moritz.angermann at gmail.com> wrote:
>
> This sent me down an interesting path.  You are right that dlopen on returns NULL with musl on x86_64, and dlerror will subsequently produce "Dynamic loading not supported" if asked to compile with -static.  I think GHC has code to fallback to archives in the case where loading shared objects fails, but I can't find the code right now.  It still means you'd need to have static sqlite (in this case) and other libraries around.
>
> I'm still a bit puzzled, and I think I'm missing something.  It remains, that I know we have musl (x86_64, aarch64) based ghcs in production.  I wonder if there is something we got right by accident, that makes this work smoothly for us.  Warrants more investigation.
>
> Cheers,
>  Moritz
>
> On Tue, Sep 29, 2020 at 7:45 PM Moritz Angermann <moritz.angermann at gmail.com> wrote:
>>
>> Happy to give this a try later today. Been using fully static musl builds (including cross compilation) for x86_64 for a while now; and did not (yet?) run into that SQLite issue. But did have it use shared objects in iserv.
>>
>> On Tue, 29 Sep 2020 at 7:18 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>>>
>>> Hi Moritz,
>>>
>>>
>>>
>>> > However dlopen with musl on x86 seems fine.
>>>
>>>
>>>
>>> Here's a dlopen example that segfaults if linked with -static:
>>>
>>>
>>>
>>> #include <stdio.h>
>>>
>>> #include <dlfcn.h>
>>>
>>>
>>>
>>> int main() {
>>>
>>>   void *h = dlopen("/usr/lib/libsqlite3.so", RTLD_NOW);
>>>
>>>   char *f = dlsym(h, "sqlite3_version");
>>>
>>>   printf("%s\n", f);
>>>
>>>   return 0;
>>>
>>> }
>>>
>>>
>>>
>>> On Tue, Sep 29, 2020 at 1:04 PM Moritz Angermann
>>>
>>> <moritz.angermann at gmail.com> wrote:
>>>
>>> >
>>>
>>> > No. Not necessarily. We can perfectly fine load archives and the pre-linked ghci objects. However dlopen with musl on x86 seems fine. On arm it’s not implemented, and just throws an error message. There is a -dynamic flag in HEAD, which disables GHC even trying to load dynamic libraries and always assuming there is no dynamic linking facility, even if configure reports the existence of dlopen...
>>>
>>> >
>>>
>>> > On Tue, 29 Sep 2020 at 6:54 PM, Cheng Shao <cheng.shao at tweag.io> wrote:
>>>
>>> >>
>>>
>>> >> Hi Ben,
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> > We will likely transition the Alpine binary distribution to be fully
>>>
>>> >>
>>>
>>> >>    statically-linked, providing a convenient, distribution-independent
>>>
>>> >>
>>>
>>> >>    packaging option for Linux users.
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> iirc for statically linked executables, musl doesn't even support
>>>
>>> >>
>>>
>>> >> dlopen, so wouldn't this mean such a bindist would fail for all
>>>
>>> >>
>>>
>>> >> LoadDLL ghci commands?
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> Cheers,
>>>
>>> >>
>>>
>>> >> Cheng
>>>
>>> >>
>>>
>>> >>
>>>
>>> >>
>>>
>>> >> On Mon, Sep 28, 2020 at 9:15 PM Ben Gamari <ben at well-typed.com> wrote:
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > Hello all,
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > The GHC team is very pleased to announce the availability of the first
>>>
>>> >>
>>>
>>> >> > alpha release in the GHC 9.0 series. Source and binary distributions are
>>>
>>> >>
>>>
>>> >> > available at the usual place:
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > This first alpha comes quite a bit later than expected. However, we have
>>>
>>> >>
>>>
>>> >> > done a significant amount of testing on this pre-release and therefore
>>>
>>> >>
>>>
>>> >> > hope to be able to move forward quickly with a release candidate next
>>>
>>> >>
>>>
>>> >> > week and with a final release in mid-October.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > GHC 9.0.1 will bring a number of new features:
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >  * A first cut of the new LinearTypes language extension [1], 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 [2]
>>>
>>> >>
>>>
>>> >> >    simplifying the type system and paving the way for QuickLook
>>>
>>> >>
>>>
>>> >> >    impredicativity in GHC 9.2.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >  * Implementation of the QualifiedDo extension [3], allowing more
>>>
>>> >>
>>>
>>> >> >    convenient overloading of `do` syntax.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >  * Improvements in compilation time.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > And many more. See the release notes [4] for a full accounting of the
>>>
>>> >>
>>>
>>> >> > changes in this release.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > Do note that there are a few things that we expect will change before
>>>
>>> >>
>>>
>>> >> > the final release:
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >  * We expect to sort out a notarization workflow for Apple Darwin,
>>>
>>> >>
>>>
>>> >> >    allowing our binary distributions to be used on macOS Catalina
>>>
>>> >>
>>>
>>> >> >    without hassle.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >    Until this has been sorted out Catalina users can exempt the
>>>
>>> >>
>>>
>>> >> >    current macOS binary distribution from the notarization requirement
>>>
>>> >>
>>>
>>> >> >    themselves by running `xattr -cr .` on the unpacked tree before
>>>
>>> >>
>>>
>>> >> >    running `make install`.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >  * We will likely transition the Alpine binary distribution to be fully
>>>
>>> >>
>>>
>>> >> >    statically-linked, providing a convenient, distribution-independent
>>>
>>> >>
>>>
>>> >> >    packaging option for Linux users.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >  * We will be merging a robust solution for #17760 which will introduce
>>>
>>> >>
>>>
>>> >> >    a new primitive, `keepAlive#`, to the `base` library, subsuming
>>>
>>> >>
>>>
>>> >> >    most uses of `touch#`.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > As always, do test this release and open tickets for whatever issues you
>>>
>>> >>
>>>
>>> >> > encounter. To help with this, we will be publishing a blog post
>>>
>>> >>
>>>
>>> >> > describing use of our new `head.hackage` infrastructure to ease testing
>>>
>>> >>
>>>
>>> >> > of larger projects with Hackage dependencies later this week.
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > Cheers,
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > - Ben
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> >
>>>
>>> >>
>>>
>>> >> > [1] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
>>>
>>> >>
>>>
>>> >> > [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
>>>
>>> >>
>>>
>>> >> > [3] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
>>>
>>> >>
>>>
>>> >> > [4] https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
>>>
>>> >>
>>>
>>> >> > _______________________________________________
>>>
>>> >>
>>>
>>> >> > 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 david.feuer at gmail.com  Tue Sep 29 21:27:58 2020
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 29 Sep 2020 17:27:58 -0400
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: <CAMgWh9uy+YHT8kMijrLEoweDbn3i36VWHG9UukfjNy8FDm=4Ag@mail.gmail.com>

Will this be updated to the latest containers before release? It's two
versions behind at the moment.

On Mon, Sep 28, 2020, 3:14 PM Ben Gamari <ben at well-typed.com> wrote:

> Hello all,
>
> The GHC team is very pleased to announce the availability of the first
> alpha release in the GHC 9.0 series. Source and binary distributions are
> available at the usual place:
>
>     https://downloads.haskell.org/ghc/9.0.1-alpha1/
>
> This first alpha comes quite a bit later than expected. However, we have
> done a significant amount of testing on this pre-release and therefore
> hope to be able to move forward quickly with a release candidate next
> week and with a final release in mid-October.
>
> GHC 9.0.1 will bring a number of new features:
>
>  * A first cut of the new LinearTypes language extension [1], 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 [2]
>    simplifying the type system and paving the way for QuickLook
>    impredicativity in GHC 9.2.
>
>  * Implementation of the QualifiedDo extension [3], allowing more
>    convenient overloading of `do` syntax.
>
>  * Improvements in compilation time.
>
> And many more. See the release notes [4] for a full accounting of the
> changes in this release.
>
> Do note that there are a few things that we expect will change before
> the final release:
>
>  * We expect to sort out a notarization workflow for Apple Darwin,
>    allowing our binary distributions to be used on macOS Catalina
>    without hassle.
>
>    Until this has been sorted out Catalina users can exempt the
>    current macOS binary distribution from the notarization requirement
>    themselves by running `xattr -cr .` on the unpacked tree before
>    running `make install`.
>
>  * We will likely transition the Alpine binary distribution to be fully
>    statically-linked, providing a convenient, distribution-independent
>    packaging option for Linux users.
>
>  * We will be merging a robust solution for #17760 which will introduce
>    a new primitive, `keepAlive#`, to the `base` library, subsuming
>    most uses of `touch#`.
>
> As always, do test this release and open tickets for whatever issues you
> encounter. To help with this, we will be publishing a blog post
> describing use of our new `head.hackage` infrastructure to ease testing
> of larger projects with Hackage dependencies later this week.
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst
> [2]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
> [3]
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst
> [4]
> https://downloads.haskell.org/ghc/9.0.1-alpha1/docs/html/users_guide/9.0.1-notes.html
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200929/4cbb6134/attachment.html>