November 2019 - Haskell-Cafe

[ANNOUNCE] GHC 8.8.1 is now available
by Ben Gamari 14 Nov '19

14 Nov '19

Hello everyone, The GHC team is pleased to announce the release candidate for GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/ghc/8.8.1 This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Visible kind applications are now supported (GHC Proposal #15) * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator significantly improving the runtime performance of some kernels * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * Users can write `forall` in more contexts (GHC Proposal #7) * The pattern-match checker is now more precise in the presence of strict fields with uninhabited types. * A comprehensive audit of GHC's memory ordering barriers has been performed, resulting in a number of fixes that should significantly improve the reliability of programs on architectures with weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 implementations). * A long-standing linker limitation rendering GHCi unusable with projects with cyclic symbol dependencies has been fixed (#13786) * Further work on the Hadrian build system * Countless miscellaneous bug-fixes Unfortunately, due to a build issue (#17108) found late in the release process i386 Windows builds are currently unavailable. These will be provided in the coming weeks. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.h…

8 14

Second call for draft papers for TFPIE 2020 (Trends in Functional Programming in Education)
by Jurriaan Hage 14 Nov '19

14 Nov '19

Hello, Please, find below the second call for draft papers for TFPIE 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Chair of TFPIE 2020 ======================================================================== TFPIE 2020 Call for papers http://www.staff.science.uu.nl/~hage0101/tfpie2020/index.html February 12th 2020, Krakow, Poland (co-located with TFP 2020 and Lambda Days) TFPIE 2020 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP and Computational Thinking FP and Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy The pedagogy of teaching FP FP and e-learning: MOOCs, automated assessment etc. Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. On top of the lecture itself, the presentation can also provide commentary on the lecture. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 20 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2020 . After the workshop, presenters will be invited to submit (a revised version of) their article for review. The PC will select the best articles that will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Dates Submission deadline: January 14th 2020, Anywhere on Earth. Notification: January 17th 2020 TFPIE Registration Deadline: January 20th 2020 Workshop: February 12th 2020 Submission for formal review: April 19th 2020, Anywhere on Earth. Notification of full article: June 6th 2020 Camera ready: July 1st 2020 Program Committee Olaf Chitil - University of Kent Youyou Cong - Tokyo Institute of Technology Marko van Eekelen - Open University of the Netherlands and Radboud University Nijmegen Jurriaan Hage (Chair) - Utrecht University Marco T. Morazan - Seton Hall University, USA Sharon Tuttle - Humboldt State University, USA Janis Voigtlaender - University of Duisburg-Essen Viktoria Zsok - Eotvos Lorand University Note: information on TFP is available at http://www.cse.chalmers.se/~rjmh/tfp/

1 0

Code coverage: mark certain function calls as covered
by Özgür Akgün 13 Nov '19

13 Nov '19

This may sound like a bizarre request, but I feel I can't be the only one. I have a function called "bug". This is essentially a special case of "error", but I am disciplined and I only use this function to mark parts of my code I believe are unreachable. So something like: data Term = X ... | Y ... | Z ... -- the argument can only be X or Y in this part of the program f :: Term -> ... f (X ...) = ... f (Y ...) = ... f Z{} = bug "This should never happen (in f)" You might hate this style of programming, and frankly I am not a fan either. But sometimes we have to write partial functions and I am at least trying to mark the cases explicitly in these cases. So this is my question: if I did a good job and if the Z case above is indeed unreachable, the code coverage report will always flag it as uncovered and in the overall report this will make it harder for me to see the parts of my code which aren't covered and should be. I'd like a way of marking (= generating a tick for?) every call to this function bug as covered. Please let me know if there is a better place to ask this question. I checked and hpc <http://hackage.haskell.org/package/hpc>'s issue tracker is shared with GHC's and I wasn't sure if they'd appreciate a question there. -- Özgür Akgün

2 1

First release of sexpresso
by Vincent Archambault-Bouffard 11 Nov '19

11 Nov '19

Hello, I'm pleased to announce the first release of the sexpresso [0] library on Hackage. sexpresso is a library to parse, print and work with S-expression. You can for example : - Customize the opening and closing tag, usually '(' and ')'. - Specify if space is needed between atoms (or between only a subset of atoms) - The datatype for S-expression (SExpr) has a extra parameter to make parsing, working and printing with multiple "type" of S-expression, like Scheme list (...) and Scheme vector #(....), easier - Do much more ... read the doc on Hackage or the README on github [1] ! I plan to improve the printer and add recursive scheme soon. [0] http://hackage.haskell.org/package/sexpresso [1] https://github.com/archambaultv/sexpresso Vincent Archambault

2 1

Help wanted: Postfix admin guru for Haskell.org
by Gershom B 10 Nov '19

10 Nov '19

We've been getting increasing amounts of bounces and dropped mail for haskell.org emails (things sent hackage trustees, things sent from our wiki and hackage servers, etc). We _mainly_ have kept things working, but it looks like policies have been amped up in terms of requiring various measures. Additionally, there's something about reverse dns and valid hostnames that seems to not be configured correctly, according to mxtoolbox. Along with all that, we'd really like to migrate the mail infrastructure to our new packet servers, away from rackspace. As such, we could use some concentrated help from someone familiar with maintaining and administering postfix servers, if someone is up to volunteer for the task. Thanks! --Gershom

2 1

Type class constraints in rewrite rules
by Janus Troelsen 09 Nov '19

09 Nov '19

Hi, I am trying to speed up some code using the Simplicity library by roconnor. He suggested I apply a rewrite rule to implement the full-adder using Haskell's addition: > fullAdder @(Kleisli m) w > into > Kleisli (\((a,b),c) -> return $ let sum = fromWord w a + fromWord w b + fromWord1 c in (toBit (sum >= 2 ^ wordSize w), toWord w sum)) I turned that description into a rewrite rule by prepending "forall m w.". But that results in "Forall'd variable ‘m’ does not appear on left hand side" and "Not in scope: type variable ‘m’" (which seems contradictory?) So I thought, OK, typically Type Applications are not necessary, I will just remove it. So the RULE becomes: "fullAdderOpt" forall w. fullAdder w = Kleisli (\((a,b),c) -> return $ let sum = fromWord w a + fromWord w b + fromWord1 c in (toBit (sum >= 2 ^ wordSize w), toWord w sum)) but compiling that, I get: > Could not deduce (Monad m) arising from a use of ‘return’". > Possible fix: add (Monad m) to the context of the RULE "fullAdderOpt" OK, that must mean I should prepend "(Monad m) =>". I tried inserting that either before or after the forall, but both variants are parse errors. So I am suspecting a GHC bug, since I was suggested to do something that doesn't parse. But really, I am just wondering how to make a rewrite rule that does what roconnor suggested. The full source code of the final version is here: https://hushfile.it/api/file?fileid=5dc706576e329 Regards, Janus

1 0

ANN: ban-instance-0.1.0.1
by Jack Kelly 08 Nov '19

08 Nov '19

I have just pushed an initial release of ban-instance[1] to Hackage. ban-instance uses template haskell to generate compile errors for typeclass instances that should not exist: -- Declare that Foo should never have a ToJSON instance $(banInstance [t|ToJSON Foo|] "why ToJSON Foo should never be defined") The custom errors then say why an instance is banned: • Attempt to use banned instance (ToJSON Foo) Reason for banning: why ToJSON Foo should never be defined Instance banned at [moduleName] filePath:lineNumber We have found this useful to prevent definition of ToJSON/FromJSON instances on core data types, as this forces programmers to instead place the serialisation instances on newtypes at the serialisation boundary. GitHub issues and PRs are welcome[2]. In particular, there are currently a few limitations: 1. There is currently no support for classes with associated types or associated data types; 2. It would be great to generate haddocks for banned instances, marking them as such; and 3. Type quotations [t|...|] do not support free variables (GHC#5616). Nevertheless, I hope that it is useful. Best, -- Jack [1]: http://hackage.haskell.org/package/ban-instance-0.1.0.1 [2]: https://github.com/qfpl/ban-instance/

1 0

[ANN] Keycloak-hs
by Corentin Dupont 07 Nov '19

07 Nov '19

Hello, I'm very proud to announce the release of Keycloak-hs, a library to access Keycloak: http://hackage.haskell.org/package/keycloak-hs. Keycloak (www.keycloak.org) is a tool allowing to authenticate users and protect your API resources. I included a tutorial in the README file. Keycloak as many many features, so this library will evolve to cover more. Help/PRs are welcome! Cheers! Corentin

1 0

Explicit approach to lazy effects For probability monad?
by Benjamin Redelings 07 Nov '19

07 Nov '19

Hi, I'm wondering if people could point me to some background on explicitly representing lazy effects in Haskell? The only effect I am concerned about at this point is `seq`. If there is a way to do this with monads, that would be great. (I know that a lot of people hate lazy effects. However, I think this is an orthogonal issue to the question of how to *represent* lazy effects explicitly.) As background, I'm using a lazy probability monad where random sampling is done with unsafeInterleaveST/IO (or something similar), so that random variables are only sampled if they are actually used: model = do x <- sample $ normal 0 1 -- the interpreter does `unsafeInterleaveIO` to implement 'sample' cond <- sample $ bernoulli 0.5 let y = if cond == 1 then x else 0 return y Here, x is only sampled if cond==1. This has a lot of benefits in procedures like Markov chain Monte Carlo. I initially thought that I could model lazy effects by mapping a -> (a,state) as in the ST monad. However, it seems like lazy effects basically require allowing forked state threads to join CONDITIONALLY on if a value is used/forced, and I don't see how to do that without a source-to-source transformation of functions. It seems like lazy effects require tracking state within each closure, and not globally within the monad interpreter. It kind of seems like this can't work if >>= has type 'm a -> (a -> m b) -> mb', assuming m a = (a,state). The second argument needs to have type (m a -> m b) instead of (a -> m b), since the computation needs to have access to the state produced by the first "m a" computation, in order to (optionally) depend on the state thread for first computation. Does this make any sense? I don't know the literature in this area. Q1. Is there a nice way of representing lazy effects that someone could point me to? Q2. Alternatively, is there a proof that either (i) there is not a monadic way to represent lazy effects, or (ii) fmap f requires a source-to-source transformation (for example to explicitly join state threads on strict operations like ($) and case). -BenRI P.S. As even more background, I'm using a probability monad that allows you to e.g. generate an infinite list of random variables, and only instantiate the ones that are looked at: model = do n <- sample $ geometric 0.5 ys <- sample $ list (repeat $ normal 0.0 1.0) zs <- take n ys return (sum zs) Here the number of random variables (n) can change over time, and I ultimately want effects to happen when they are instantiated. There is a brief overview at http://www.bali-phy.org/models.php

2 2

Performance difference parallel 'toString'
by Donald Cordes 06 Nov '19

06 Nov '19

Hi everybody, I'm trying to squeeze more performance out of Haskell, and I'm hoping someone can help me understand why the following two pieces of code have different performance. In particular, I find that the apparently 'more parallel' version of the code performs worse. Quick description of the code: basically it solves the following problem [https://www.spoj.com/problems/PALIN/] The input is a set of huge integer numbers. For each number, print the smallest 'palindrome' that is larger. A palindrome is a number for which when you reverse its digits you end up with the same number. The code uses 'parBuffer' to do the calculations in parallel. Below is high-level description of the steps of each version: Version 1 [palin.parfromstring.hs]: 1. Read the input numbers as strings into a list 2. Perform the following calculation for each number (the steps for this calculation run in sequence, the entire calculation runs in parallel w.r.t. different numbers): 2.1 Convert from string to array of digits 2.2 Calculate the palindrome in-place The result of step 2 is a list of digit-arrays. That concludes the parallel step. 3. For each palindrome, convert it to a string and print it. Version 2 [palin.parfromstringtostring.hs]: 1. Same as above 2.1 Same as above 2.2 Same as above 2.3 Convert the palindrome to a string 3. For each string, print it. I'd expect that version 2 is faster than version 1 because it's doing the conversion back to string also in parallel, but on a set of 50 numbers it's surprisingly ~750ms slower on my computer. I see that the GC is doing a lot more copying for version 2 (1GB more than version 1), but I don't really understand what I'm looking it. :) How can one best think about getting more performance out of parallelism in Haskell? As in, what are some good rules of thumb by which one can decide 'parallelize this, don't parallelize that'? Attached you can find the event logs for ThreadScope and full code for each version. The code is almost identical, so attached is also the diff between the two. Thanks in advance

1 0