Re: Not all splices are the same
Seems related to https://gitlab.haskell.org/ghc/ghc/-/issues/18211 There is also a small section in my thesis (4.1.2) which explains why changing the implementation of typed quotations would allow this program to be accepted. Matt On Sun, Jan 23, 2022 at 7:08 PM David Feuer wrote: > > I've been a bit upset by the challenges Template Haskell poses for type > inference. For example, > > (3 :: Int) == $$(...) > > may typecheck when > > $$(...) == (3 :: Int) > > does not. I don't imagine this problem can be solved in general, but I'm > rather curious whether it might be possible to solve for "pure" splices, with > types that look like > > forall m. Quote m => Code m a > > Would it be possible to get full bidirectional inference for these if they > were somehow marked specially by the user? For instance, if I wrote > > $$$e > > that could mean e should be interpreted as having some type > > PCode a > > where > > newtype PCode a = PCode (forall m. Quote m => a) > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Not all splices are the same
I've been a bit upset by the challenges Template Haskell poses for type inference. For example, (3 :: Int) == $$(...) may typecheck when $$(...) == (3 :: Int) does not. I don't imagine this problem can be solved in general, but I'm rather curious whether it might be possible to solve for "pure" splices, with types that look like forall m. Quote m => Code m a Would it be possible to get full bidirectional inference for these if they were somehow marked specially by the user? For instance, if I wrote $$$e that could mean e should be interpreted as having some type PCode a where newtype PCode a = PCode (forall m. Quote m => a) ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
any luck using "retrie" refactoring tool on GHC sources?
I'm trying to use the retrie refactoring tool, but I'm getting a mysterious error message: nr@homedog ~/a/g/compiler [1]> retrie --adhoc "forall x . not (backendNeedn'tLink x) == backendNeedsLink x" parseAdhocs:1:80: error: parse error on input ‘#-}’ retrie: user error (parse failed) The Tool was installed using cabal install; its github page is https://github.com/facebookincubator/retrie/#readme. Has anybody had any success using this tool on the GHC sources? I'd love a workaround, or just advice. Norman ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell] [ANNOUNCE] GHC 9.0.2 released
There's no such directory in the Hackage or GitHub source. I guess it must have crept in on the GHC side? On Sun, Jan 23, 2022, 4:13 AM Jens Petersen wrote: > On Sun, 23 Jan 2022 at 15:40, David Feuer wrote: > >> Could you explain what you mean about the containers source not being >> "clean"? >> > > I forgot to say "in the source tarball" explicitly. > If you look in libraries/containers/containers/dist-install, you can see > what I am talking about. > (I first discovered this because it broke the Fedora build - so I just > remove it before building.) > > Jens > > On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote: >> >>> First of all a big thank you and congratulations on the highly >>> anticipated 9.0.2 release. >>> >>> I have been putting off this mail for a while: >>> I actually built it last month right away in Fedora's new ghc9.0 package >>> (available now for all current Fedora releases). >>> Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to >>> 9.0.2, since nightly-2022-01-10. :-) >>> >>> However two points I wanted to mention: >>> >>>- firstly (minor), the libraries/containers source is not clean >>>(which explains why the tarball is so big) >>> >>> >>>- More serious: why was Win32 major bumped from 2.10 to 2.12? >>> - this breaks foundation, hence current Stackage Nightly is kind >>> of broken for Windows now: >>> https://github.com/commercialhaskell/stackage/issues/6400 >>> >>> I can't really see any good way to resolve this in the short term. >>> >>> Thanks, Jens >>> >>> >>> On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote: >>> The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/). ___ >>> Glasgow-haskell-users mailing list >>> glasgow-haskell-us...@haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell] [ANNOUNCE] GHC 9.0.2 released
On Sun, 23 Jan 2022 at 15:40, David Feuer wrote: > Could you explain what you mean about the containers source not being > "clean"? > I forgot to say "in the source tarball" explicitly. If you look in libraries/containers/containers/dist-install, you can see what I am talking about. (I first discovered this because it broke the Fedora build - so I just remove it before building.) Jens On Sun, Jan 23, 2022, 2:31 AM Jens Petersen wrote: > >> First of all a big thank you and congratulations on the highly >> anticipated 9.0.2 release. >> >> I have been putting off this mail for a while: >> I actually built it last month right away in Fedora's new ghc9.0 package >> (available now for all current Fedora releases). >> Also Stackage Nightly (primarily thanks to Adam Bergmark) was updated to >> 9.0.2, since nightly-2022-01-10. :-) >> >> However two points I wanted to mention: >> >>- firstly (minor), the libraries/containers source is not clean >>(which explains why the tarball is so big) >> >> >>- More serious: why was Win32 major bumped from 2.10 to 2.12? >> - this breaks foundation, hence current Stackage Nightly is kind >> of broken for Windows now: >> https://github.com/commercialhaskell/stackage/issues/6400 >> >> I can't really see any good way to resolve this in the short term. >> >> Thanks, Jens >> >> >> On Sun, 26 Dec 2021 at 04:23, Zubin Duggal wrote: >> >>> The GHC developers are very happy to at long last announce the >>> availability of GHC 9.0.2. Binary distributions, source distributions, >>> and documentation are available at the >>> [usual place](https://downloads.haskell.org/ghc/9.0.2/). >>> >>> ___ >> Glasgow-haskell-users mailing list >> glasgow-haskell-us...@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell] [ANNOUNCE] GHC 9.0.2 released
I wrote WinIO a couple of times when I meant to type Win32. Sorry! On 23 January 2022 1:32:15 pm IST, Zubin Duggal wrote: > >> - More serious: why was Win32 major bumped from 2.10 to 2.12? >> - this breaks foundation, hence current Stackage Nightly is kind of >> broken for Windows now: >> https://github.com/commercialhaskell/stackage/issues/6400 > >We needed to bump Win32 as per a request from the maintainer made at >https://gitlab.haskell.org/ghc/ghc/-/issues/20017 > >Bumping it from 2.10.0 to 2.10.1.0 ran into >https://github.com/haskell/win32/issues/174, which was fixed by >https://github.com/haskell/win32/pull/175 > >Given this, our options at the time were: > >1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32 > >2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10, >which is what caused WinIO/#174 > >3) Use Win32 2.12.0.1, which contains the requested fix(ghc/#20017), as >well as the explicit exports added by #175, along with a few other minor >changes from Win32 2.11 which I don't think are responsible for any of >the pain discussed in the stackage issue. > >I made the decision to go with option 3 in the interests of getting the >release out. > >However, if I understand correctly, we would still end up with the same >problems as brought up in the stackage issue if we went with option 1. > >We might have avoided some of this pain if we went with option 2 and >reverted the offending commits from WinIO 2.10 instead of using explicit >import lists. But removing features from a major release of a library >didn't seem like a good idea at a time, and would have delayed the 9.0.2 >release even more. > >I hope this makes the reasoning for the decision clearer, and I >do apologise for any pain caused. I did believe that under the >circumstances bumping WinIO to 2.12.0.1 was the best way forward. >Perhaps option 2 would have been better in retrospect, but at the >time the benefits for such a change (in particular the regression in >functionality) in a major release of Win32 were not so clear. > >Cheers, >Zubin >___ >Glasgow-haskell-users mailing list >glasgow-haskell-us...@haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell] [ANNOUNCE] GHC 9.0.2 released
- More serious: why was Win32 major bumped from 2.10 to 2.12? - this breaks foundation, hence current Stackage Nightly is kind of broken for Windows now: https://github.com/commercialhaskell/stackage/issues/6400 We needed to bump Win32 as per a request from the maintainer made at https://gitlab.haskell.org/ghc/ghc/-/issues/20017 Bumping it from 2.10.0 to 2.10.1.0 ran into https://github.com/haskell/win32/issues/174, which was fixed by https://github.com/haskell/win32/pull/175 Given this, our options at the time were: 1) Backport pull request #175 to 2.10.1 and wait for a new release of Win32 2) Revert https://github.com/haskell/win32/pull/160 in Win32 2.10, which is what caused WinIO/#174 3) Use Win32 2.12.0.1, which contains the requested fix(ghc/#20017), as well as the explicit exports added by #175, along with a few other minor changes from Win32 2.11 which I don't think are responsible for any of the pain discussed in the stackage issue. I made the decision to go with option 3 in the interests of getting the release out. However, if I understand correctly, we would still end up with the same problems as brought up in the stackage issue if we went with option 1. We might have avoided some of this pain if we went with option 2 and reverted the offending commits from WinIO 2.10 instead of using explicit import lists. But removing features from a major release of a library didn't seem like a good idea at a time, and would have delayed the 9.0.2 release even more. I hope this makes the reasoning for the decision clearer, and I do apologise for any pain caused. I did believe that under the circumstances bumping WinIO to 2.12.0.1 was the best way forward. Perhaps option 2 would have been better in retrospect, but at the time the benefits for such a change (in particular the regression in functionality) in a major release of Win32 were not so clear. Cheers, Zubin ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
