- Haskell-Cafe - Haskell.org

Journal of Functional Programming - Call for PhD Abstracts
by Graham Hutton 04 May '20

04 May '20

============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st May 2020 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton <graham.hutton(a)nottingham.ac.uk> by 31st May 2020: o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

cost of Text.Parsec.Expr
by Johannes Waldmann 03 May '20

03 May '20

Dear Cafe, I use `buildExpressionParser` https://hackage.haskell.org/package/parsec-3.1.14.0/docs/Text-Parsec-Expr.h… with a table similar to https://hackage.haskell.org/package/haskell-src-exts-1.23.0/docs/Language-H… and I find it's somewhat expensive. I think the algorithm makes me pay for each operator that is in the table even when just a few of them are actually in the input. (I removed from the table those that don't appear in my test cases, and it got faster.) Certainly this is known? What could be done about it? What does Megaparsec do? It seems that Text.Megaparsec.Expr vanished from version 6 to version 7. A classical shift/reduce algorithm would help (?) but not with the given type of table, which does not allow to parse an operator just once, and then look up its precedence. - J.W.

3 2

ICFP 2020 will be held ONLINE Aug 23-28
by Sam Tobin-Hochstadt 02 May '20

02 May '20

The ICFP 2020 organizers would like to announce that the conference and co-located events, originally scheduled for August 23-28, in Jersey City, New Jersey, will now be held online during the same dates. Further information for presenters, authors, attendees, sponsors, and the ICFP community will be provided as it becomes available. The ICFP Organizing Committee

1 0

[Haskell-Cafe] How to deal with looped references inside instances?
by Daneel Yaitskov 01 May '20

01 May '20

{- Hi, I am trying to translate a Java sample with looped references below to Haskell. I've found 2 solutions, but both of them look ugly, because they require a helper class. So I am looking for an advice for best practices on working with looped references in polymorphic types. interface Engine { String showEng(); } class Car<E extends Engine> { int id; E eng; String show() { return "Car with " + eng.showEng(); } int getId() { return id; } } class Steam implements Engine { Car<Steam> car; Stream(Car<Steam> car) { this.car = car; } String showEng() { return "id " + car.getId(); } } Car<Steam> car = new Car<>(); car.id = 42; car.eng = new Stream(car); car.show(); -} {-# LANGUAGE UndecidableInstances #-} -- Fix2 shortcoming class Car c where getId :: c -> Int class Engine e where showEng :: e -> String data SteamEng c = SteamEng c instance (Car c) => Engine (SteamEng c) where showEng (SteamEng c) = "id " ++ show (getId c) {- First solution is via ShowEng class. I don't know how to tell type checker that the type which is got after application of type function is instantiating Engine class?? instance (Engine eng) => Show (Car1 eng) where show (Car1 _ eng) = "Car1 with " ++ showEng eng -} data Car1 eng = Car1 Int (eng (Car1 eng)) class ShowEng f where showEng2 :: (Car a) => f a -> String instance ShowEng SteamEng where showEng2 = showEng {- A side note. Intuitive alternative for ShowEng which is not working! showEng2 = showEng means showEng2 gets Engine, but class HaveEngine f where cast :: (Car a) => f a -> f a instance HaveEngine SteamEng where cast = id ... instance (HaveEngine eng) => Show (Car1 eng) where show (Car1 _ eng) = "Car1 with " ++ (showEng (cast eng)) nor instance (HaveEngine eng) => Show (Car1 eng) where show (Car1 _ eng) = "Car1 with " ++ (showEng eng) -} instance Car (Car1 e) where getId (Car1 id _) = id instance (ShowEng eng) => Show (Car1 eng) where show (Car1 _ eng) = "Car1 with " ++ (showEng2 eng) c1 = Car1 42 (SteamEng c1) {- Second solution is removing argument from engine type parameter. -} data Car0 eng = Car0 Int eng instance Car (Car0 e) where getId (Car0 id _) = id instance (Engine eng) => Show (Car0 eng) where show (Car0 _ eng) = "Car0 with " ++ showEng eng {- in this case I have to avoid infinite type and introducing an extra wrapper and instantiating business logic classes for him. λ c0 = Car0 42 (SteamEng c0) <interactive>:30:6: error: • Occurs check: cannot construct the infinite type: car ~ Car0 (SteamEng car) • In the expression: Car0 (SteamEng c0) In an equation for ‘c0’: c0 = Car0 42 (SteamEng c0) • Relevant bindings include c0 :: car (bound at <interactive>:30:1) -} newtype Fix2 f g = Fix2 (f (g (Fix2 f g))) instance (Show (f (g (Fix2 f g)))) => Show (Fix2 f g) where show (Fix2 a) = show a {- λ c0 = Car0 42 (SteamEng (Fix2 c0)) <interactive>:62:1: error: • No instance for (Car (Fix2 Car0 SteamEng)) arising from a use of ‘print’ • In a stmt of an interactive GHCi command: print it -} instance (Car (f (g (Fix2 f g)))) => Car (Fix2 f g) where getId (Fix2 a) = getId a c0 = Car0 42 (SteamEng (Fix2 c0)) {- Thanks, Daniil -}

2 1

A quick poll about GHC's -with-rtsopts flag
by Merijn Verstraaten 01 May '20

01 May '20

Who here is: 1) Aware that multiple invocations of -with-rtsopts clobber each other, and 2) Actually relies on this behaviour? This quick and informal poll in relation to this GHC issue: https://gitlab.haskell.org/ghc/ghc/issues/18117 Cheers, Merijn

4 3

ANN: stack-2.3.1
by Emanuel Borsboom 01 May '20

01 May '20

See https://haskellstack.org/ for installation and upgrade instructions. Release notes: - We have reduced the number of platforms that we support with binary releases. The reason behind this is that we've been slowed down in our release process until now with issues trying to build binaries for less common platforms. In order to make sure we can address issues more quickly (like supporting new GHC versions), we're limiting support from the Stack team to: - Linux 64-bit (static) - macOS - Windows 64-bit If others want to provide additional binaries, we will definitely be happy for the support. But since our CI system is currently able to produce these three bindists only, that's what we will be providing with the next release. - Since we no longer have dynamically linked Linux binaries, we are removing removing the -static suffix from the static Linux binaries. If you have scripts to download the latest stable Linux binary, update them to use linux-x86_64 instead of linux-x86_64-static (if you are already using the former, nothing needs to change). For this release, both are supported, but the next release will no longer have the -static variant. - We are also deprecating the download links at https://stackage.org/stack. See this page for the current installation instructions: https://docs.haskellstack.org/en/stable/install_and_upgrade/. - These are the canonical locations to download the latest stable binaries from, and will continue to be supported going forward: - Linux 64-bit (static): https://get.haskellstack.org/stable/linux-x86_64.tar.gz - macOS: https://get.haskellstack.org/stable/osx-x86_64.tar.gz - Windows 64-bit: https://get.haskellstack.org/stable/windows-x86_64.zip As always, binaries for specific versions are available from the Github releases: https://github.com/commercialhaskell/stack/releases. *Changes since v2.1.3.1* Major changes: - setup-info-locations yaml configuration now allows overwriting the default locations of stack-setup-2.yaml. #5031 <https://github.com/commercialhaskell/stack/pull/5031> #2983 <https://github.com/commercialhaskell/stack/issues/2983> #2913 <https://github.com/commercialhaskell/stack/issues/2913> - The setup-info configuration key now allows overwriting parts of the default setup-info - The --setup-info-yaml command line flag now may be used in all stack commands such as stack build, and not only in stack setup - The --setup-info-yaml may specify multiple locations for stack-setup.yaml files. - The stack upload can read first reads environment Variable $HACKAGE_USERNAME and $HACKAGE_PASSWORD if they are missing only then asks for username or password - Fully remove GHCJS support. - Remove the freeze command. It has been replaced by lock files. Behavior changes: - Remove the deprecated --stack-setup-yaml command line argument in favor of --setup-info-yaml #2647 <https://github.com/commercialhaskell/stack/issues/2647> - We now recommend checking in generated cabal files for repos. When generating lock files for extra-deps that only include package.yaml files, a deprecation warning will be generated. Also, those packages will no longer be included in the generated lock files. See #5210 <https://github.com/commercialhaskell/stack/issues/5210>. Other enhancements: - Add build-output-timestamps flag in yaml. Setting it to true prefixes each build log output line with a timestamp. - Show warning about local-programs-path with spaces on windows when running scripts. See #5013 <https://github.com/commercialhaskell/stack/pull/5013> - Add ls dependencies json which will print dependencies as JSON. ls dependencies --tree is now ls dependencies tree. See #4424 <https://github.com/commercialhaskell/stack/pull/4424> - Remove warning for using Stack with GHC 8.8-8.10, and Cabal 3.0-3.2. - Allow relative paths in --setup-info-yaml and tool paths #3394 <https://github.com/commercialhaskell/stack/issues/3394> - Added the --only-locals flag. See #5272 <https://github.com/commercialhaskell/stack/issues/5272> Bug fixes: - Upgrade pantry: module mapping insertions into the database are now atomic. Previously, if you SIGTERMed at the wrong time while running a script, you could end up with an inconsistent database state. - --resolver global doesn't retrieve snapshots list from the internet beause doesn't need it. See #5103 <https://github.com/commercialhaskell/stack/issues/5103> - Fix using relative links in haddocks output. See #4971 <https://github.com/commercialhaskell/stack/issues/4971>. - Do not include generated cabal file information in lock files. See #5045 <https://github.com/commercialhaskell/stack/issues/5045>. - Use proper Hoogle executable path when installed automatically. See #4905 <https://github.com/commercialhaskell/stack/issues/4905> - Fix GHC version for batched package unregistration. See #4951 <https://github.com/commercialhaskell/stack/issues/4951> - Use Hoogle from the snapshot used and not the latest version. See #4905 <https://github.com/commercialhaskell/stack/issues/4905> - Resolve "'stty' is not recognized". See #4901 <https://github.com/commercialhaskell/stack/issues/4901> - Fix missing reconfigure check causing errors when a package gets used in multiple projects. See #5147 <https://github.com/commercialhaskell/stack/issues/5147> *Thanks to all our contributors for this release:* - Adam McCullough - Akshay Mankar - Brian Wignall - Cheah Jer Fei - Chris Done - David Baynard - davit nalchevanidze - Dino Morelli - Emanuel Borsboom - Felix Yan - flip111 - Flowers Safety - Fred Miller - Fyrbll - gdziadkiewicz - Good boy - Hypnoes.Liu - Iisus - Iustin Pop - ivanbakel - Javier Neira - Jeff Happily - jeffhappily - jneira - Justin Le - Kirill Zaborsky - Leif Metcalf - Leonhard Markert - Lokesh Mohanty - Matt Audesse - Michael Snoyman - Mihai Maruseac - NightRa - Phil Ruffwind - qinzhenlong - Robert Hensing - Sasha Bogicevic - Sibi - Sibi Prabakaran - Simon Michael - Steve Mao - Vlad Ki - Xia Li-yao

2 2

Re: [Haskell-cafe] Please repair Hugs-for-Windows download links
by Anthony Clayden 30 Apr '20

30 Apr '20

Hi Vanessa, Thorkil, Yes I'm afraid Hugs is unmaintained. If you look at that Hugs-Bugs thread, Neil was kind enough to reply, but it seems everyone is locked out of maintaining the site. > Isn’t hugs unmaintained? Cool stuff but definitely vintage! (Nearly) gone, but not forgotten. There's a few people over the years have built from source, there's a few repos on github. With a bit of time on my hands lately ... I've built the wonderful WinHugs from source, so that I can fix a long-standing bit of bogusness in GHC. (GHC's behaviour is just not worth trying to make sense of.) And ref the discussion of GHC's awkwardness wrt Windows, WinHugs is just so nicely Windows-y, with a few-clicks install. Persuading (Win)Hugs to compile wasn't plain sailing, and there's a few of the libraries/packages have bitrotted beyond repair. But it is sooooo worth it, compared to the ugly GHC experience; plus you get a half-decent records system with Trex. (I've just been adding field label puns to it, to catch up with GHC.) AntC >* On Apr 26, 2020, at 10:25 AM, Thorkil Naur via Haskell-Cafe <haskell-cafe at haskell.org <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote: *> >* Dear Cafe, *> >* Having recently had occasion to suggest the use of Hugs, I found that the *>* links provided for WinHugs and MinHugs on *> >* https://www.haskell.org/hugs/pages/downloading.htm <https://www.haskell.org/hugs/pages/downloading.htm> *> >* are broken. In the discussion "When did it become so hard to install *>* Haskell on Windows?" *> >* https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html <https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132129.html> *> >* Anthony Clayden *> >* https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132155.html <https://mail.haskell.org/pipermail/haskell-cafe/2020-April/132155.html> *> >* referred to *> >* https://mail.haskell.org/pipermail/hugs-bugs/2018-July/001914.html <https://mail.haskell.org/pipermail/hugs-bugs/2018-July/001914.html> *> >* which provides working links: *> >* https://www.haskell.org/hugs/downloads/2006-09/WinHugs-Sep2006.exe <https://www.haskell.org/hugs/downloads/2006-09/WinHugs-Sep2006.exe> *>* https://www.haskell.org/hugs/downloads/2006-09/MinHugs-Sep2006.exe <https://www.haskell.org/hugs/downloads/2006-09/MinHugs-Sep2006.exe> *> >* If someone with suitable access repaired these links, I would be very *>* grateful. I am an occasional user of both GHC and Hugs, and although GHC *>* shines when it comes to efficiency, I also often appreciate the modest *>* and simple Hugs. *> >* Thanks very much in advance. *> >* Best regards *>* Thorkil *

3 2

Re: [Haskell-cafe] When did it become so hard to install Haskell onWindows?
by Anthony Clayden 29 Apr '20

29 Apr '20

> I think the comments regarding users' proficiency with Chocolatey or PowerShell or whatever are beside the point. The truth is that *nobody* expects that anyone would need to be familiar with those tools in order to install software on Windows. As an example of what I'm talking about, consider Microsoft Visual Studio. This is a big, complex piece of software. And, obviously, it's an application that's used by software developers, rather than ordinary end users. During installation, it runs multiple PowerShell and Cmd scripts, and, for all I know, uses Chocolatey under the hood as well. The point is, I don't have to care about any of that. I install it the same way I install any other software in Windows: I click a few buttons and make a few checkbox selections, and it just runs*. Indeed, my experience too. Furthermore MSVC/Visual Studio upgraded the source distro 'Solution' for Hugs/WinHugs from 2006; and I could go ahead and build that with less than a dozen patches to bitrotted code and config. No sight of a command line needed. In comparison, building the Unixy bits was a nightmare. (And I think little of that was Windows-specific or mixed-platform specific.) > I understand perfectly well the issue with resource constraints preventing the creation of a better experience for Windows users. ... I don't understand. SLPJ is at *Microsoft*; his homepage is at *Microsoft*; his email address is *@Microsoft*. It's ironic that half of the threads Simon starts on ghc-devs relate to crashes/failed builds on *Windows*. And here we are (not for the first time) using up disproportionate airspace on Windows. I appreciate the sponsorship (in effect) the GHC community gets from Microsoft. Could their help provide a little more practical benefit?: there are surely Microsofters who know the tools and have the skills to deliver a few-clicks installer for GHC(?) > And I think it's safe to assume that Microsoft has a few more resources at its disposal to support this than the Haskell community does. So you just need to be honest about it, and state up front that there isn't a simple, seamless way to install the Haskell Platform in Windows at this time, but if you want to install it anyway, here's what you need to do. AntC

1 0

Re: [Haskell-cafe] Hugs sources WITH TESTS?
by Anthony Clayden 29 Apr '20

29 Apr '20

Hi Siddharth, Hugs dates from a different age, when testing was something of an afterthought. I can suggest some places to look: * The hugs-bugs mailing list is the only way to (possibly) contact the original developers. * There's a couple of repos on github: Franklin Chen, Chris Done. Franklin has also grabbed the 2009 developer snapshot. But I suspect the answer is: there are no tests/never were. AntC > I got interested in hugs thanks to the surrounding discussion and went spelunking in their codebase. Weirdly, I can't find a test suite! - The November 2003 version <https://github.com/bollu/hugs/blob/master/src/Makefile.in#L280> has a rule in the makefile to cd ../tests . However, such a folder does not exist in the source tree. - the September 2006 version <https://github.com/haskell-implementations/hugs/blob/master/src/Makefile.in>, doesn't have a test / check rule at all. I find this baffling. Where did the tests go?! If you have access to them --- or if you the story behind where the tests are, please do let me know!

1 0

Problem with publishing project/packages
by Dominik Schrempf 28 Apr '20

28 Apr '20

Hello, I am not sure if this is the right place to report/discuss the following issue, but I have been fiddling around with properly publishing a project I am developing in Haskell for quite some time now. I have encountered various difficulties that I would like to share and hear your opinion about, and also your suggestions about what I could improve, and probably also, how the Haskell ecosystem could be improved. First, I use Stack+Hpack to manage `.cabal` files. I know, that this combination has summoned many controversies, but I don't want to spend hours fiddling around in my `.cabal` files and on the version bounds, so decided for this option. I use strict PVP bounds (--pvp-bounds both options), so that at least compilation should be reproducible, albeit only allowing the specific set of library versions present in the Stack resolver. My project does heavy numerical calculations, so I was awaiting the support of LLVM9.0, which will come with GHC 8.10, for a long time. In the meantime, I tried to compile and publish my project in its current state with the newest Stack resolver 15.x with GHC 8.8.3. On my local machine, compilation and the development cycle work reasonably well, but as soon as I try to publish my work, I have serious trouble. First, I encountered an issue with auto generated modules of the packages causing trouble in the `.cabal` files generated by Hpack [1]. I think this is because the Cabal specification was improved (i.e., has changed), and new specifications have to be honored. I try to work around the issue by directly specifying the newest Cabal specification 3.0 and by tinkering around with the flags, until Hpack produces files compatible with the newest version of Cabal. Finally, I can create source tarballs with `stack sdist --pvp-bounds both`. However, I cannot upload these tarballs, because somehow, the created `.cabal` files in the source tarballs include dependencies of the following form: `base : {} >= x.y, <= z.a` (or something similar), and Hackage chokes on this form (is this a new syntax? or is it just a bug?). So I think, maybe this is caused by an incompatibility of Stack with my Cabal or cabal-install version, which are newer than the newest ones officially supported by Stack. I had already lost one day of working time at this point. I did not give up, but decided to install a Cabal version officially supported by Stack. Also, I removed all my dependencies on auto-generated modules from the packages and the `.cabal` files, I reverted other changes I had implemented because of the Cabal specification change (for example, reverting all license identifiers). I managed to compile and publish my project on Hackage. However, Hackage is not able to compile the packages and show the documentation (which is what I need most). Because I am going the easy route, and use strict PVP bounds, Hackage cannot compile my packages because they depend on base >= 4.13, and Cabal version 3.0. It took me another hour or so, to find out that the official package repository of Haskell does not support the official base library which has been published over six months ago. From a users point of view, this is unacceptable. I have found some resources about this issue now, but I was not aware of this discrepancy before experiencing it. So my next thought is: "Let's just put it on Stackage, because the best days of Hackage seem to be over...". However, I cannot do that, because my project needs to compile on Hackage in order to be put on Stackage... I guess all this is consequence of using an operating system with up-to-date packages (Arch Linux), and my inherent demand to use the newest compiler, and so on. However, I feel that it is not entirely my fault, the new compiler with the new base libraries should be supported by the official repository, and in a coherent way by the most widely used build tools Cabal and Stack (which uses Hpack by default, by the way). I sincerely apologize for being so harsh, but I am angry at the ecosystem, and angry at myself, because, obviously, I don't know enough to get things done. Thanks for your feedback, it is appreciated! Dominik Schrempf References: [1] https://github.com/sol/hpack/issues/384 [2] In case of interest, the project I am developing is a set of libraries/binaries to be used in evolutionary biology https://github.com/dschrempf/elynx

5 14