November 2020 - ghc-devs

Adding a way to reduce type families in type errors
by Jakob Brünker 22 Nov '20

22 Nov '20

Hi all, While there is a way to expand type synonyms in type errors (-fprint-expanded-synonyms), as far as I know, the same doesn't exist for type families. For example, the following type family Foo a where Foo Int = String type family Bar a :: Maybe (Foo Int) where Bar a = '() results in the error Expected kind `Maybe (Foo Int)', but '() has kind `()' where I'd like to see "Expected kind `Maybe String'". I'd be interested in trying my hand at implementing a way to see this, either by adding it to -fprint-expanded-synonyms, or as a new flag. Three questions: - Is there already a way to do this that I'm missing? - Are there reasons for why this would be a bad idea? - Would a proposal be necessary for this? Thanks, Jakob

2 2

Re: Use of forall as a sigil
by Andrey Mokhov 22 Nov '20

22 Nov '20

Hi Richard, > In the end, I've never loved the forall ... -> syntax, but I've never seen > anything better. What about the forall @a. syntax? For example: sizeOf :: forall @a. Sized a => Int We already use @ to explicitly specify types, so it seems natural mark type parameters that must be explicitly specified with @ too. Here's how one would read it: "for all explicitly specified a, ..." Apologies if this has been discussed and I missed it. It doesn't seem to be mentioned in the Alternatives section of the proposal but perhaps it will just never work for some reason. Cheers, Andrey

3 3

Correct way of extending the context of the typechecker
by Yiyun Liu 20 Nov '20

20 Nov '20

Hi ghc-devs, Recently we've been trying to merge the typeclass branch of Liquid Haskell into the develop branch (link to the PR: https://github.com/ucsd-progsys/liquidhaskell/pull/1778) Since we want GHC to typecheck the refinements, we had to add some predefined logic symbols such as ==> to the global environment of GHC. In our branch, we use execStmt to add those extra symbols to the interactive context. This is no longer possible after LH becomes available as a GHC plugin because the plugin lives in TcRn. It seems that the only way is to directly interact with the typechecker and explicitly add the extra symbols to the context. It is not obvious to me how that can be done without accidentally breaking the invariants of the compiler. I wonder if there are examples or certain files that I can look into to learn how to interact with the typechecker? Adding the extra symbols is probably not that difficult, but I'd also want to acquire some general knowledge of how the typechecker works to further the integration between LH and GHC so we can remove some of the hacks on our end. Thanks, -Yiyun

2 1

Question about HsWrapper for constructors
by Kai-Oliver Prott 18 Nov '20

18 Nov '20

Hi all, I've tried a development snapshot of GHC's master branch from the beginning of this month and I am curious about the reason for a specific change. I noticed that a simple program like idNil :: [a] -> [a] idNil [] = [] is internally represented (after type checking) as: AbsBinds [] [] {Exports: [idNil <= idNil2] Exported types: idNil :: forall a. [a] -> [a] Binds: idNil2 [] = (/\(@a2). [] @a2) @a Can someone point me to a reason why the right side of idNil2 is not represented as [] @ a, like it was in GHC 8.10.1? I have not tried it with GHC 9.0. It is interesting to have a type lambda that is immediately followed by a type application. Thanks, Kai

2 1

Searching on GitLab
by Richard Eisenberg 07 Nov '20

07 Nov '20

Hi all, Some time ago, I set up a keyword bookmark (https://www-archive.mozilla.org/docs/end-user/keywords.html <https://www-archive.mozilla.org/docs/end-user/keywords.html>) to search in tickets and MRs, by using a Google "site:gitlab.haskell.org/ghc/ghc/issues/ <http://gitlab.haskell.org/ghc/ghc/issues/> %s" query. About a year ago, I noticed that the quality of results decreased to the point of uselessness, and I started to use GitLab's built-in search. This works fine, but it's not as good as Google's. Today, I discovered why the quality went down: GitLab changed its URLs. Previously, a ticket lived at e.g. gitlab.haskell.org/ghc/ghc/issues/1234 <http://gitlab.haskell.org/ghc/ghc/issues/1234>. Today, it lives at gitlab.haskell.org/ghc/ghc/-/issues/1234 <http://gitlab.haskell.org/ghc/ghc/-/issues/1234>. GitLab automatically redirects from the former to the latter, so old links/bookmarks still work great. But Google's search doesn't! The solution was easy: just update my keyword bookmarks to include the extra /-. Better search results, cooked up fresh. Perhaps you want some, too -- hence this email. Enjoy, Richard

1 0

Re: Status of #10071 (class method deprecations)
by Richard Eisenberg 06 Nov '20

06 Nov '20

My take (not authoritative) is that some good ideas were floated, but nothing was decided on. Given that we now have a proper process for deciding on new features, I think we should use it, and go via a proposal. Note that I've fixed the link in the original description to point to https://gitlab.haskell.org/ghc/ghc/-/wikis/design/deprecation-mechanisms/ty… Richard > On Nov 6, 2020, at 1:22 AM, Fumiaki Kinoshita <fumiexcel(a)gmail.com> wrote: > > I stumbled upon a case where I want to deprecate a class method in favour of another (https://github.com/fumieval/witherable/pull/68 <https://github.com/fumieval/witherable/pull/68>), which reminded me of some discussion around Monad-of-no-return proposal. > > There seems to be an old ticket, but I'm not sure what the status is -- > is this approved and waiting for implementation, or something which needs to be resubmitted to ghc-proposals? > https://gitlab.haskell.org/ghc/ghc/-/issues/10071 <https://gitlab.haskell.org/ghc/ghc/-/issues/10071> > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Announcing the Haskell Foundation
by Richard Eisenberg 04 Nov '20

04 Nov '20

I'm very pleased to announce the creation of the Haskell Foundation (HF), an independent, non-profit organisation dedicated to broadening Haskell adoption. Website: https://haskell.foundation/ <https://haskell.foundation/> Twitter: @haskellfound Founding whitepaper: https://haskell.foundation/whitepaper/ <https://haskell.foundation/whitepaper/> Simon Peyton Jones's announcement, with lots of Q&A: https://www.youtube.com/watch?v=MEmRarBL9kw <https://www.youtube.com/watch?v=MEmRarBL9kw> The "official" ask-me-anything on Reddit: https://www.reddit.com/r/haskell/comments/jnwg7i/haskell_foundation_ama/ <https://www.reddit.com/r/haskell/comments/jnwg7i/haskell_foundation_ama/> Mailing list for future HF announcements: https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-announce <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-announce> Mailing list for HF discussion / involvement: https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss <https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss> Please join the conversation. We need your participation to realize the vision of the foundation as *our* foundation, not *their* foundation. Looking forward to seeing where this all leads! Richard

1 0

Re: msys woes
by Shayne Fletcher 03 Nov '20

03 Nov '20

On Sun, Nov 1, 2020 at 12:44 PM Ben Gamari <bgamari(a)gmail.com> wrote: > Shayne Fletcher <shayne.fletcher.50(a)gmail.com> writes: > > > On Thu, Oct 8, 2020 at 1:18 PM Phyx <lonetiger(a)gmail.com> wrote: > > > >> From the looks of it the repo.msys2.org system doesn't have enough > space > >> to restore all these old packages. > >> > >> So we'll have to handle it on our end. The easiest way to get your > builds > >> working again is by applying a patch with the fix to the source tree. > >> > >> > > New problems in this space as of today. This time with > > ```bash > > > > stack --stack-yaml stack.yaml --resolver nightly-2020-01-08 exec -- > > pacman -S autoconf automake-wrapper make patch python tar mintty > > --noconfirm > > ``` > > > > which produces 404 errors > > Oh dear; thank you for raising this with upstream, Shayne! Let's hope > there is action soon. > > After looking into it a bit, I'm beginning to think that it is in fact on us (stack as it happens) to upgrade our msys installer. I have a workaround for now: ``` stack exec -- curl -O http://repo.msys2.org/msys/x86_64/msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz stack exec -- pacman -U msys2-keyring-r21.b39fb11-1-any.pkg.tar.xz --noconfirm stack exec -- pacman -Syu autoconf automake-wrapper make patch python tar mintty --noconfirm" ``` -- Shayne Fletcher

1 1

Tomorrow: Simon PJ announces Haskell Foundation
by Richard Eisenberg 03 Nov '20

03 Nov '20

Tomorrow (Wednesday Nov 4) at 12:00 UTC, Simon PJ will announce the formation of the Haskell Foundation, an independent, non-profit organization dedicated to broadening Haskell adoption. This will be a part of Haskell eXchange, but this announcement will be free to attend, via YouTube. Much of the presentation will be time for Q&A; questions can be posed both within the Haskell eXchange HopIn platform and via comments on YouTube. Attend at https://youtu.be/MEmRarBL9kw <https://youtu.be/MEmRarBL9kw> Just to forestall any disappointment: I won't be answering any questions here until at least after the announcement -- but do please come and ask questions there and afterwards. Richard

1 0

Re: msys woes
by Shayne Fletcher 01 Nov '20

01 Nov '20

On Thu, Oct 8, 2020 at 1:18 PM Phyx <lonetiger(a)gmail.com> wrote: > From the looks of it the repo.msys2.org system doesn't have enough space > to restore all these old packages. > > So we'll have to handle it on our end. The easiest way to get your builds > working again is by applying a patch with the fix to the source tree. > > New problems in this space as of today. This time with ```bash stack --stack-yaml stack.yaml --resolver nightly-2020-01-08 exec -- pacman -S autoconf automake-wrapper make patch python tar mintty --noconfirm ``` which produces 404 errors ``` 2020-11-01T16:02:47.2564782Z :: Retrieving packages... 2020-11-01T16:02:49.0237771Z error: failed retrieving file 'diffutils-3.6-1-x86_64.pkg.tar.xz' from repo.msys2.org : The requested URL returned error: 404 2020-11-01T16:02:49.3752086Z error: failed retrieving file 'diffutils-3.6-1-x86_64.pkg.tar.xz' from downloads.sourceforge.net : The requested URL returned error: 404 2020-11-01T16:02:49.8476086Z error: failed retrieving file 'diffutils-3.6-1-x86_64.pkg.tar.xz' from www2.futureware.at : The requested URL returned error: 404 2020-11-01T16:02:49.8482030Z warning: failed to retrieve some files 2020-11-01T16:02:51.2288388Z error: failed retrieving file 'autoconf-2.69-3-any.pkg.tar.xz' from repo.msys2.org : The requested URL returned error: 404 2020-11-01T16:02:51.3674499Z error: failed retrieving file 'autoconf-2.69-3-any.pkg.tar.xz' from downloads.sourceforge.net : The requested URL returned error: 404 2020-11-01T16:02:51.4787091Z error: failed retrieving file 'autoconf-2.69-3-any.pkg.tar.xz' from www2.futureware.at : The requested URL returned error: 404 2020-11-01T16:02:51.4791763Z warning: failed to retrieve some files ... ``` I've raised https://github.com/msys2/MSYS2-packages/issues/2225 with msys2. -- Shayne Fletcher

1 0