- Glasgow-haskell-users

I discovered that the uu-options package does not compile due to a dependency on lenses, which does not compile with GHC 8.4
by Doaitse Swierstra 11 Jul '18

11 Jul '18

In case you want to try here is an updated lenses package. Best, Doaitse PS: I contacted Job (the author) in order to get things updated

1 0

Testing that packages still compile
by Sébastien Hinderer 03 Jul '18

03 Jul '18

Dear all, I am part of the OCaml development team. As you may know, OCaml has a package manager a bit similar to cabal whose name is opam. One of my colleagues spends quite a lot of time trying to make sure that packages still compile with a new version of the compiler, when we release it. When a package does not compile any longer, it seems it is a highly non-trivial task to figure out what exactly is broken: is it the package itself which has been broken by a change in the compiler, or is it one of its dependencies. I am assuming the same kind of problems occur with Haskell and am wondering how they are handle. Has there been something published on this kind of problem? Any pointer, comment or contact appreciated. Best wishes, Sébastien.

4 4

2nd Call for Talks -- Haskell Implementors' Workshop
by Joachim Breitner 02 Jul '18

02 Jul '18

Call for Contributions ACM SIGPLAN Haskell Implementors’ Workshop https://icfp18.sigplan.org/track/hiw-2018-papers Co-located with ICFP 2018 St. Louis, Missouri, US https://conf.researchr.org/home/icfp-2018 Important dates --------------- Proposal Deadline: Friday, 20 July, 2018 Notification: Friday, 3 August, 2018 Workshop: Sunday, 23 September, 2018 Keynote speaker --------------- This year, the Haskell Implementors’ Workshop is proud to present Rahul Muttineni as the keynote speaker. Rahul brough the joys of Haskell to the realm of Java by creating the Eta programming language. Title: Let's Go Mainstream with Eta! Eta is a fork of GHC that focuses on three core principles: user experience, performance, and safety. We'll discuss how we used these principles to guide the re-implementation of the GHC runtime and code generator on the JVM. Moreover, will also cover the inner workings of the FFI and the typechecker support we added for subtyping to make it smooth to interact with Java libraries. Finally, we'll round out with a look at where Eta is headed and how Eta and GHC can collaborate in the future. About the Haskell Implementors’ Workshop ---------------------------------------- The 10th Haskell Implementors’ Workshop is to be held alongside ICFP 2018 this year in St. Louis. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2018. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw18.hotcrp.com/ until July 20th (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Program Committee ----------------- * Edwin Brady (University of St. Andrews, UK) * Joachim Breitner – chair (University of Pennsylvania) * Ben Gamari (Well-Typed LLP) * Michael Hanus (Kiel University) * Roman Leshchinsky (Facebook) * Niki Vazou (University of Maryland) Contact ------- * Joachim Breitner <joachim(a)cis.upenn.edu> -- Joachim Breitner Post-Doctoral researcher http://cis.upenn.edu/~joachim

1 0

[ANNOUNCE] GHC 8.6.1-alpha1 available
by Ben Gamari 02 Jul '18

02 Jul '18

The GHC development team is pleased to announce the first alpha release leading up to GHC 8.6.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-alpha1 This is the first release (partially) generated using our new CI infrastructure. One known issue is that the haddock documentation is currently unavailable. This will be fixed in the next alpha release. Do let us know if you spot anything else amiss. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben

2 3

[ANNOUNCE] GHC 8.4.3 released
by Ben Gamari 31 May '18

31 May '18

Hello everyone, The GHC team is pleased to announce the availability of GHC 8.4.3. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.4.3 This release includes a few bug fixes including: * A code generation bug resulting in crashing of some programs using UnboxedSums has been fixed (#15038). * #14381, where Cabal and GHC would disagree about abi-depends, resulting in build failures, has been worked around. Note that the work-around patch has already been shipped by several distributions in previous releases, so this change may not be visible to you. * By popular demand, GHC now logs a message when it reads a package environment file, hopefully eliminating some of the confusion wrought by this feature. * GHC now emits assembler agreeable to newer versions of Gnu binutils, fixing #15068. * SmallArray#s can now be compacted into a compact region Thanks to everyone who has contributed to developing, documenting, and testing this release! As always, let us know if you encounter trouble. How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://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. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. 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: 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/TeamGHC 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 1

The dreaded windows path length issue
by Erik de Castro Lopo 30 May '18

30 May '18

Hi all, I'm now working for IOHK on the Cardano project. The Cardano code base is large and we are hitting the dreaded windows path length bug. We have already shortned build paths as much as possible but are still hitting this We're currently using ghc-8.0.2 but even ghc-8.2.2 has this issue. A snippet of the logs in included below. I took the liberty of including Tamar on this since he is the known Windows expert. Not having a local Window makes this really difficult to debug. Anyone have any solutions for this? I'm willing to backport patches if needed. I've managed to find a VirtualBox evaluation image on the Microsoft site. Hopefully that will give me enough to debug this issue. Cheers, Erik [01:27:27] -- While building custom Setup.hs for package csl-wallet-new-1.1.1 using: [01:27:27] C:\s\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.w\dist\5c8418a7 build lib:csl-wallet-new exe:cardano-node exe:csl-gen-swagger exe:csl-integ-test test:wallet-new-specs test:wallet-unit-tests --ghc-options " -ddump-hi -ddump-to-file" [01:27:27] Process exited with code: ExitFailure 1 [01:27:27] Logs have been written to: C:\w\.w\logs\csl-wallet-new-1.1.1.log [01:27:27] [01:27:27] Configuring csl-wallet-new-1.1.1... [01:27:27] Preprocessing library for csl-wallet-new-1.1.1.. [01:27:27] Building library for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-new-specs' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'cardano-node' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-gen-swagger' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Building test suite 'wallet-unit-tests' for csl-wallet-new-1.1.1.. [01:27:27] Preprocessing executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Building executable 'csl-integ-test' for csl-wallet-new-1.1.1.. [01:27:27] Linking .w\dist\5c8418a7\build\csl-integ-test\csl-integ-test.exe ... [01:27:27] realgcc.exe: error: CreateProcess: No such file or directory [01:27:27] `gcc.exe' failed in phase `Linker'. (Exit code: 1) [01:27:27] Command "call stack --dump-logs install cardano-sl cardano-sl-tools csl-wallet csl-wallet-new -j 2 --no-terminal --local-bin-path c:\w --test --no-haddock-deps --flag cardano-sl-core:-asserts --flag cardano-sl-tools:for-installer --flag csl-wallet:for-installer --extra-include-dirs="C:\OpenSSL-Win64-v102\include" --extra-lib-dirs="C:\OpenSSL-Win64-v102" --extra-include-dirs="C:\xz_extracted\include" --extra-lib-dirs="C:\xz_extracted\bin_x86-64" --extra-include-dirs="c:\w\rocksdb\include" --extra-lib-dirs="c:\w"" failed with exit code 1. Retrying 4 of 5 -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

2 1

Natural number comparisons with evidence
by Conal Elliott 24 May '18

24 May '18

When programming with GHC's type-level natural numbers and `KnownNat` constraints, how can one construct *evidence* of the result of comparisons to be used in further computations? For instance, we might define a type for augmenting the results of `compare` with evidence: > data CompareEv u v > = (u < v) => CompareLT > | (u ~ v) => CompareEQ > | (u > v) => CompareGT Then I'd like to define a comparison operation (to be used with `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy arguments): > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v With `compareEv`, we can bring evidence into scope in `case` expressions. I don't know how to implement `compareEv`. The following attempt fails to type-check, since `compare` doesn't produce evidence (which is the motivation for `compareEv` over `compare`): > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > LT -> CompareLT > EQ -> CompareEQ > GT -> CompareGT Can `compareEv` be implemented in GHC Haskell? Is there already an implementation of something similar? Any other advice? Thanks, -- Conal

5 10

Re: Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]
by Anthony Clayden 21 May '18

21 May '18

On Wed, 9 May 2018 03:01 UTC, cheater00 wrote: > I couldn't live without ScopedTypeVariables. For me it's an essential tool when I want to figure out Yes absolutely. To be clear: nobody's talking about removing it. The question is, could we get the same functionality without being so confusing and contrary to how Haskell usually works with type variables? (I'm not saying yea or nay, I'm trying to invite discussion.) > ... > Backwards compat: Isn't this what we have Haskell 98, Haskell 2010, etc? The current design for ScopedTypeVariables potentially changes the types for programs that are valid H98/H2010. (Or for programs that were valid as at when ScopedTypeVariables was introduced ~10 years ago, perhaps using ExplicitForAll.) Probably the effect would be that they don't compile, but it might be more subtle. So the explanation I've seen for the current design is it was deliberately idiosyncratic, to minimise any disruption to existing code. Then I'm asking whether any of that code is still around? If not/if it's been re-factored to use ScopedTypeVariables, then any tweak to the design could have a freer hand. But seems there's no enthusiasm for such discussion, so I'm going to let it die. I hear there might be moves afoot elsewhere ... AntC

3 5

PSA for Cabal 2.2 new-* users regarding .ghc.environment files
by Gershom B 13 May '18

13 May '18

There is an important change in the cabal new- commands for 2.2 that the release docs should have highlighted more significantly. Cabal new-* commands now produce a .ghc.environment file by default. These files [1] are picked up by ghc and ghci automatically (since 8.0.1), and allow them to operate directly with the same package environment used by the new-* commands. This lets you, for example, run `ghci` in a project where you are using `new-build` and get the proper dependencies in scope. Herbert has written an experimental tool to make it easier to create and manipulate these environments [2]. However: there is a drawback (on which some discussion at [3] and [4]. In particular, there is not good information provided by ghc about when these files are picked up and used. So if you are admixing new-* commands and other commands for the time being, jumping between the two, or admixing ghc and ghcjs, etc., then you may run into unexpected behavior! [5] The simplest solution for now is to delete the local .ghc.environment file in those cases (i.e. where you're mixing commands and get unexpected behavior). A particular gotcha is that these files are picked up not just in the current directory but also in any parent directory. Cheers, Gershom [1] documented at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.ht… [2] https://github.com/hvr/cabal-env [3] https://github.com/haskell/cabal/issues/4542 [4] https://ghc.haskell.org/trac/ghc/ticket/13753 [5] Error messages may be like ".cabal/store/ghc-8.0.2/package.db/package.cache: openBinaryFile: does not exist (No such file or directory)" or complaints about missing inplace dependencies.

3 2

Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]
by Anthony Clayden 09 May '18

09 May '18

This thread is a discussion about discussions, not the discussion itself ;-) I'm cc'ing to the cafe; but I'd prefer replies to come to glasgow-haskell-users. >> I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll get ignored.) > ... don’t care what forums or list or whatever. As long as it’s collated and such > It could even be on the prime issue tracker for prime proposals. Just that it’s written down :) Thanks Carter, but I understand Haskell Prime to be to assess mature/stable proposals (preferably already delivered as extensions). This discussion is at first going to be more exploratory: * likes and dislikes about ScopedTypeVariables as currently. * confusions experienced by users (especially newbies) -- although absolute newbies wouldn't be using it(?), so intermediates? * feedback from those teaching Haskell. * wild ideas for possible alternative designs. * possible improvements to the current design. * I think we're all agreed that ScopedTypeVariables should have been in Haskell from the beginning; but it wasn't, so now we have to worry about backwards compatibility for programs that worked around the omission. Or do we? What code would break? How much pain would that cause? * anything else? > We have lots of forums, but your point is that certain sorts of discussions never get going with the right audience – you especially point to “confused beginners”. > ... It’s quite a challenge because beginners tend not to be vocal, and yet they are a crucial set of Haskell users. Every Haskell user started as a beginner. On this particular topic, there's plenty of confused people asking questions on StackOverflow. (Heads up: they're especially asking why they need explicit `forall` whereas in reguar Haskell that 'intermediates' see, the forall is implicit.) Can other people point me to questions/likes/dislikes on other forums? Reddit for example. If you've read this far, you now understand what we're trying to cover. It's going to be random/varied thoughts at first, then perhaps coalescing to an approach or two. At that point a formal proposal on github proper; and the random stuff might be interesting background but will essentially get archived/thrown away. I do agree with David's suggestion that github Issue tracker looks like a suitable solution. We can write formatted code and text. We can add links and references. What do others think? Joachim has opened up Issues tracker, as a try-out. If using it doesn't work out, that's fine and in keeping with my "thrown away" above. Also where else should I post links to this message to 'advertise' the thread? I don't reddit much, so if that's suitable, please someone post there. Thank you AntC

2 1