- Glasgow-haskell-users

unsafeCoerce shenanigans
by David Feuer 12 Feb '18

12 Feb '18

Suppose I have a function of type unionWith# :: (Hashable k, Eq k) => (a -> a -> (# a #)) -> HashMap k a -> HashMap k a -> HashMap k a I can use this to implement strict and lazy unions with practically no code duplication either in source or in generated code: S.unionWith, L.unionWith :: (Hashable k, Eq k) => (a -> a -> a) -> HashMap k a -> HashMap k a -> HashMap k S.unionWith f = unionWith# (\a b -> let !r = f a b in (# r #)) L.unionWith f = unionWith# (\a b -> (# f a b #)) Semantically, this gets the job done, but there's a potential performance problem. If the function passed to either version of unionWith fails to inline, then we'll build a closure to interface with the underlying function. This is not so great, because it adds indirection in a likely hot spot. I'm not too terribly worried about the lazy version, because it's prone to leaking memory anyway, but I do care about the strict version. It seems to me that for the *strict* version, I can probably use unsafeCoerce to do the job instead: S.unionWith f = unionWith# (unsafeCoerce f) When unionWith# applies f to values, it will get back something that it *thinks* might be a thunk, but actually will never be a thunk. We don't really care, especially because we just stick it into a lazy constructor field. My main concern is that this is obviously not at all an officially supported way to use unsafeCoerce. What are the chances that GHC will do something that breaks it? If I can't do this reliably, I should still be able to use unionWith# to reduce *source* size, relying on lots of inlining to avoid closures, but the generated code would stay large. David

1 0

Quantified Constraints and Injectivity
by Anthony Clayden 12 Feb '18

12 Feb '18

I’m looking at the flurry of activity around Quantified Constraints [1, 2, 3], suggestion of uses for implication logic [4], and comments in the hs2017 paper “raise the expressive power of type classes … to first-order logic. … more expressive modelling …”[Abstract]. Consider modelling the logic for somewhat-injective type functions. Take type-level Boolean `And` [5]. `And` is not fully injective but: * If the result is True, the two arguments must be True. * If the result is False and one argument is True, the other must be False. class ( b3 ~ True => (b1 ~ True, b2 ~ True), (b3 ~ False, b1 ~ True) => b2 ~ False ) -- etc => And (b1 :: Bool) (b2 :: Bool) (b3 :: Bool) | b1 b2 -> b3 where … None of this is relying on `Bool` being a closed type AFAICT. (That’s the usual downfall of trying to capture application logic in constraints.) Come to that, can we capture the logic of the FunDep? (The hs2017 paper hints we might.) class ( {- as before -}, ( forall b3’. And b1 b2 b3’ => b3’ ~ b3 ) ) => And (b1 :: Bool) (b2 :: Bool) (b3 :: Bool) | b1 b2 -> b3 where … This might come closer to the logic of FunDeps as originally specified by Mark P Jones, which ghc doesn’t quite reach to [6]. OTOH we now have a cyclical superclass constraint, which ain’t allowed. [1] https://github.com/ghc-proposals/ghc-proposals/pull/109 [2] https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints [3] https://ghc.haskell.org/trac/ghc/ticket/2893 [4] https://mail.haskell.org/pipermail/libraries/2017-December/028377.html [5] https://mail.haskell.org/pipermail/ghc-devs/2017-November/015073.html, continued at https://mail.haskell.org/pipermail/glasgow-haskell-users/2017-November/0266… [6] https://ghc.haskell.org/trac/ghc/ticket/10675 AntC

1 0

[ANNOUNCE] GHC 8.4.1-alpha3 available
by Ben Gamari 06 Feb '18

06 Feb '18

The GHC development team is pleased to announce the third and likely last alpha release leading up to GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha3 Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release is still affected by #14675, wherein the compiler will segmentation fault when built with some Ubuntu toolchains. We are actively working to identify the cause and hope that this will be resolved before the final release. === 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 preceded 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 into users' hands and more quickly identify potential issues. 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

1 0

(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 22 Jan '18

22 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 19 Jan '18

19 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 05 Jan '18

05 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