The Windows Task Force roster is here: https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce A couple months ago I was looking into some of the linker issues (one manifestation of which was failure to link in mingw under TH phases as in #10672), but I was sadly unable to make much headway. I'm still interested in cracking this as Windows is my primary development platform, but new leads are required. Eventually, I may just seek a ground-up understanding of linkers in Windows and mingw. If anyone else has leads, please let me know if I can help. Cheers, Darren On Sun, Aug 9, 2015 at 5:00 AM, wrote:

Send ghc-devs mailing list submissions to ghc-devs@haskell.org

To subscribe or unsubscribe via the World Wide Web, visit http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs or, via email, send a message with subject or body 'help' to ghc-devs-request@haskell.org

You can reach the person managing the list at ghc-devs-owner@haskell.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of ghc-devs digest..."

Today's Topics:

1. Linking issue on Windows: #10672 (Richard Eisenberg) 2. Re: Linking issue on Windows: #10672 (John Wiegley) 3. Type checker error messages question (Jack Bowman)

----------------------------------------------------------------------

Message: 1 Date: Sat, 8 Aug 2015 14:23:31 -0400 From: Richard Eisenberg To: ghc-devs Devs Subject: Linking issue on Windows: #10672 Message-ID: <8839B562-9A83-4137-A0D6-5DC15137C9C6@cis.upenn.edu> Content-Type: text/plain; charset=us-ascii

Hi devs,

Bug #10672 was posted two weeks ago and has not received any response. It concerns linking issues on Windows with Template Haskell. This is very far out of my depth, but I don't recognize the name of the poster (lukexi), and so it would be great to let that person know we've received the report and have at least triaged it. Who are the Windows task force? I can't seem to find that listed on https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, but perhaps there's a better place to look.

If you have any idea of what's going on, would you mind at least commenting on the bug?

Thanks! Richard Template Haskell czar but linking buffoon and Windows ignoramus

------------------------------

Message: 2 Date: Sat, 08 Aug 2015 12:35:25 -0700 From: "John Wiegley" To: Richard Eisenberg Cc: ghc-devs Devs Subject: Re: Linking issue on Windows: #10672 Message-ID: Content-Type: text/plain

...

...

...

...

...

Richard Eisenberg writes:

...

If you have any idea of what's going on, would you mind at least commenting on the bug?

I would also like to know who knows what about which linking platforms we support.

John

------------------------------

Message: 3 Date: Sat, 8 Aug 2015 22:56:00 -0400 From: Jack Bowman To: ghc-devs@haskell.org Subject: Type checker error messages question Message-ID: < CACcVNgUgbw9WLocN7dFM5Wewh8WbG4d81MwNmZQhcSedoSJEVQ@mail.gmail.com> Content-Type: text/plain; charset="utf-8"

Hi all, I'm new to the GHC codebase and am looking to contribute. I started trying to implement https://ghc.haskell.org/trac/ghc/ticket/9173 , "better type error messages". I'm having some difficulty and was hoping someone more experienced could point me in the right direction. Part of the proposed change is that the "inferred:" line lists both the expression ("Just 5") and its type ("Maybe a0"). That's good because it's more clear that way. Currently those are in different parts of the error message. The function misMatchMsg (TcErrors.hs) creates the text "couldn't match expected type...". The text "In the second argument of..." is created by funAppCtxt (TcExpr.hs) during type checking. Bringing these together seems tricky. When we're generating a message like "couldn't match expected type..." I don't see how to access the expression text, like the "LHsExpr Name"s available to funAppCtxt. Is there an easy way to get that? We have the constraint and the two types, but I don't think those include this info. It seems fundamental to the error messages that the context ("in the _ argument..., in the expression ...") is built up as *text* while we do type checking, which means it's hard to customize when building the final error message. Please let me know if I'm missing something. There's a lot of type checker state that I might be misunderstanding. Thanks,Jack