- Glasgow-haskell-users

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

[ANNOUNCE] GHC 8.2.2 released
by Ben Gamari 15 Dec '17

15 Dec '17

=============================================== The Glasgow Haskell Compiler -- version 8.2.2 =============================================== The GHC Team is pleased to announce a new minor release of GHC. This release builds on the performance and stability improvements of 8.2.1, fixing a variety of correctness bugs, improving error messages, and making the compiler more portable. Notable bug-fixes include * A correctness issue resulting in segmentation faults in some FFI-users (#13707, #14346) * A correctness issue resulting in undefined behavior in some programs using STM (#14171) * A bug which may have manifested in segmentation faults in out-of-memory condition (#14329) * clearBit of Natural no longer bottoms (#13203) * A specialisation bug resulting in exponential blowup of compilation time in some specialisation-intensive programs (#14379) * ghc-pkg now works even in environments with misconfigured NFS mounts (#13945) * GHC again supports production of position-independent executables (#13702) * Better error messages around kind mismatches (#11198, #12373, #13530, #13610) A thorough list of the changes in the release can be found in the release notes, https://haskell.org/ghc/docs/8.2.2/html/users_guide/release-8-2-2.html How to get it ~~~~~~~~~~~~~ This release can be downloaded from https://www.haskell.org/ghc/download_ghc_8_2_2.html For older versions see https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Background ~~~~~~~~~~ Haskell is a standardized lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating efficient code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces. GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page https://www.haskell.org/ghc/ GHC developers' home page https://ghc.haskell.org/trac/ghc/ Haskell home page https://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://mail.haskell.org/cgi-bin/mailman/listinfo Many GHC developers hang out on #haskell on IRC: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug

2 2

Re: [was ghc-devs] Reasoning backwards with type families
by Anthony Clayden 14 Dec '17

14 Dec '17

> On Thu Nov 16 01:31:55 UTC 2017, David Feuer wrote: (Moving to ghc-users, there's nothing particularly dev-y.) > Sometimes it woulld be useful to be able to reason backwards > about type families. Hi David, this is a well-known issue/bit of a sore. Discussed much in the debate between type families compared to FunDeps. > For example, we have > > type family a && b where > 'False && b = 'False > 'True && b = b > a && 'False = 'False > a && 'True = a > a && a = a > ... if we know something about the *result*, > GHC doesn't give us any way to learn anything about the arguments. You can achieve the improvement you want today. You'll probably find Oleg has a solution With FunDeps and superclass constraints, it'll go like this class (OnResult r a b, OnResult r b a) => And a b r | a b -> r instance And 'False b 'False -- etc, as you'd expect following the tf equations -- the instances are overlapping but confluent class OnResult r a b | r a -> b instance OnResult 'True a 'True instance OnResult 'False 'True 'False You could equally make `OnResult` a type family. If you can trace backwards to where `&&` is used, you might be able to add suitable constraints there. So there's a couple of futures: * typechecker plugins, using an SMT solver * injective type families the next phase is supposed to allow type family a && b = r | r a -> b, r b -> a where ... That will help with some type families (such as addition of Nats), plug1 https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/propo… but I don't see it helping here. plug2 (this example) https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/propo… Because (for example) if you unify the first two equations, (that is, looking for coincident overlap) 'False && 'False = 'False 'True && 'False = 'False That's inconsistent on dependency ` r b -> a`. And you can't fix it by re-ordering the closed equations. > For (&&), the obvious things you'd want are ... > > There's nothing inherently impossible about this sort of reasoning. No-ish but. It relies on knowing kind `Bool` is closed. And GHC doesn't pay attention to that. So you need to bring type family `Not` into the reasoning; hence a SMT solver. > ... > I wouldn't necessarily expect GHC > to be able to work something like this out on its own. That's a relief ;-) > But it seems like there should be some way to allow the user > to guide it to a proof. Yes, an SMT solver with a model for kind `Bool`. (And a lot of hard work to teach it, by someone.) AntC

4 9

How to uninstall all cabal packages?
by Volker Wysk 03 Dec '17

03 Dec '17

Hi! I want to remove eveything which cabal has installed, and begin again with a clean installation. How is this accomplished? I've deleted ~/.cabal, but it still says that hsshellscript is already installed: desktop ~ $ cabal install hsshellscript Resolving dependencies... All the requested packages are already installed: hsshellscript-3.4.3 Use --reinstall if you want to reinstall anyway. Bye V.W.

3 4

Rewrite rules involving LHS lambda?
by Conal Elliott 03 Dec '17

03 Dec '17

Is there a written explanation and/or examples of rewrite rules involving a LHS lambda? Since rule matching is first-order, I'm wondering how terms with lambda are matched on the LHS and substituted into on the RHS. For instance, I want to restructure a lambda term as follows: > foo (\ x -> fmap u v) = bar (\ x -> u) (\ x -> v) My intent is that the terms `u` and `v` may contain `x` and that whatever variable name is actually used in a term being rewritten is preserved so as to re-capture its occurrences on the RHS. When I write this sort of rule, I get warnings about `x` being defined but not used. Thanks, -- Conal

4 4

uninstalling libraries
by Evan Laforge 14 Nov '17

14 Nov '17

For a very long time, I've used a local script to uninstall libraries. Initially it was very simple: use ghc-pkg field to find and remove library-dirs, import-dirs, and haddock-html, and call ghc-pkg unregister. It served well for a long time, but eventually I got tired of copy paste games and extended it to be able to recursively delete dependents too. Unfortunately now it's no longer so simple. The main problem is that the only way I know to find dependents is to ghc-pkg unregister, and see what the error message complains about. That's obviously pretty bad, since by that time you've already unregistered, so it's too late to back out. The non-atomic nature of unregister+rm has always caused problems anyway, since if unregister succeeds, but the remove fails, we are stuck with a partial install. Recursive delete is too error prone, so I reverted that. And then I discovered that hmatrix helpfully includes /opt/local/lib and /usr/local/lib in its library-dirs, so clearly just deleting whatever the package tells me is not very safe. All this has led me to believe uninstalling packages is not so simple, and maybe there should be an actual real way to do it, not everyone hacking up their own dangerous shell scripts. So... is there? Should there be one? Is there interest in one? How do other people uninstall libraries? Is there a better interface to the pkg db than ghc-pkg? Is there a better way to find dependents than ghc-pkg unregister?

4 8