January 2018 - Glasgow-haskell-users

(Failing to) look up names generated by Template Haskell
by Ranjit Jhala 26 Jan '18

26 Jan '18

Hi all, I am stuck on the following problem. Suppose you have two module Lib Client where Client "imports" Lib. Now, while analyzing the Core of `Client` often I need to resolve the name of a `TyThing` defined inside `Lib`. Normally, this is easy enough: I simply use hscTcRcLookupName :: HscEnv <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/HscT…> -> Name <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/Name…> -> IO <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/base-4.10.0.0/…> (Maybe <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/base-4.10.0.0/…> TyThing <https://downloads.haskell.org/~ghc/8.2.1/docs/html/libraries/ghc-8.2.1/Type…> ) defined inside HscMain. **THE PROBLEM** However, I find that when the relevant `Name` corresponds to something generated by TemplateHaskell (inside `Lib`) then the above `hscTcRcLookupName` fails to return any result! Even more oddly, suppose the name was BlogPostId If there are TWO `TyThing`s with that name, e.g. a type synonym defined type BlogPostId = ... and also a data constructor for a data family instance, then `hscTcRcLookupName` only returns the type synonym, but refuses to return the data constructor. Does anyone know what may be going on? Thanks! - Ranjit Jhala.

1 1

[ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 23 Jan '18

23 Jan '18

The GHC development team is pleased to announce the first alpha release of the 8.4.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha1 Note that this release drops compatibility with GCC 4.6 and earlier. While we generally try to place as few constraints on system toolchain as possible, this release depends upon the __atomic__ builtins provided by GCC 4.7 and later (see #14244). === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceeded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes in to users hands and allow better feedback on the status of the release. GHC 8.4 is slated to be released in mid-February but, due to technical constraints, we are starting the alpha-release cycle a bit later than planned under the above schedule. For this reason, it would be greatly appreciated if users could put this alpha through its paces to make up for lost time. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

3 7

Why is EvTerm limited?
by Joachim Breitner 20 Jan '18

20 Jan '18

Hi, I had some funky idea where a type checker plugin would have to synthesize code for a custom-solved instances on the fly. But it seems that does not work because EvTerm is less expressive than Core (especially, no lambdas): https://downloads.haskell.org/~ghc/8.2.2/docs/html/libraries/ghc-8.2.2/TcEv… What would break if we had | EvExpr CoreExpr as an additional constructor there? Cheers, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

2 1

Maybe String -> CoreExpr in a GHC plugin
by Joachim Breitner 19 Jan '18

19 Jan '18

Hi, in a GHC plugin, I want to synthesize simple data structures, and insert them into the code. What is the most idiomatic way of writing a function, say, foo :: Maybe String -> CoreExpr or foo :: Maybe String -> CoreM CoreExpr so that the resulting CoreExpr describes the input. Abstractly speaking, I could imagine creating the Core AST by hand (but I’d have to figure out how to resolve the names of the constructors), or somehow invoking the renamer, type-checker and desugarer from within CoreM. Surely someone else has solved this problem before. How did you do it? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

1 1

Re: PSA: `cabal update` command needs manual unsticking
by Donn Cave 06 Jan '18

06 Jan '18

Quoth Nathan Collins <nathan.collins(a)gmail.com>, > I had some ~/.cabal/packages/hackage.haskell.org/00-index.* files, but > not any 01-index.* files, and running `cabal update` didn't change > that. I see this when using hackage.fpcomplete.com, rather than hackage.haskell.org. (The latter is very slow for me, and sometimes fails - $ cabal update Downloading the latest package list from hackage.haskell.org dieVerbatim: user error (cabal: '/bin/curl' exited with an error: curl: (18) transfer closed with 29508193 bytes remaining to read )$ ) Donn

1 0

Re: [Haskell-cafe] PSA: `cabal update` command needs manual unsticking
by Brandon Allbery 05 Jan '18

05 Jan '18

Correct: cabal-install 1.x still uses the old index format (00-index). The logic is different for 01-index, in order to support incremental update (appending when possible, instead of always having to download the whole thing again like with 00-index). On Thu, Jan 4, 2018 at 1:38 PM, Nathan Collins <nathan.collins(a)gmail.com> wrote: > In case this confuses anyone else, I think this PSA only applies if > you're using cabal-install version 2.*, but please correct me if I'm > wrong. > > I had some ~/.cabal/packages/hackage.haskell.org/00-index.* files, but > not any 01-index.* files, and running `cabal update` didn't change > that. Then I noticed I was using cabal-install version 1.24.0.2. When > I upgraded to cabal-install version 2.0.0.1 and did another `cabal > update` the 01-index.* files appeared. > > Cheers, > > -nathan > > On Mon, Jan 1, 2018 at 5:24 PM, Gershom B <gershomb(a)gmail.com> wrote: > > Dear Haskellers, > > > > A recent update to hackage, which fixed up the 01-index.tar.gz file, > > revealed a bug in existing versions of cabal-install, when index files > > are cleaned up. This bug means that the `cabal update` command, which > > updates the hackage index file, will fail silently and leave the old > > file in place. It is easy to get things working again, but it requires > > manual intervention. Here is the most straightforward way to get > > things working again: > > > > On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.* > > On windows: remove the same files, but from > > %appdata%\cabal\packages\hackage.haskell.org > > > > rerun `cabal update` to fetch a new 01-index. > > > > Apologies all for the inconvenience and any confusion this may have > > caused. There is a PR to fix this behavior in the works, but since the > > problem is on the client side, the fix will only improve the > > situations for new versions of `cabal`. > > > > Happy New Years to all, and cheers to a very functional 2018, > > Gershom > > > > p.s.: since the problem comes in unpacking the 01-index.tar.gz into > > the 01-index.tar, you can also just untar that file in place manually, > > or force cabal into doing the same by running `touch > > ~/.cabal/packages/hackage.haskell.org/01-index.tar` > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com ballbery(a)sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

2 1

PSA: `cabal update` command needs manual unsticking
by Gershom B 02 Jan '18

02 Jan '18

Dear Haskellers, A recent update to hackage, which fixed up the 01-index.tar.gz file, revealed a bug in existing versions of cabal-install, when index files are cleaned up. This bug means that the `cabal update` command, which updates the hackage index file, will fail silently and leave the old file in place. It is easy to get things working again, but it requires manual intervention. Here is the most straightforward way to get things working again: On gnu/linux or mac: rm ~/.cabal/packages/hackage.haskell.org/01-index.* On windows: remove the same files, but from %appdata%\cabal\packages\hackage.haskell.org rerun `cabal update` to fetch a new 01-index. Apologies all for the inconvenience and any confusion this may have caused. There is a PR to fix this behavior in the works, but since the problem is on the client side, the fix will only improve the situations for new versions of `cabal`. Happy New Years to all, and cheers to a very functional 2018, Gershom p.s.: since the problem comes in unpacking the 01-index.tar.gz into the 01-index.tar, you can also just untar that file in place manually, or force cabal into doing the same by running `touch ~/.cabal/packages/hackage.haskell.org/01-index.tar`

3 2