- Haskell-Cafe - Haskell.org

Call for Tutorial Participation: ICFP 2020
by Sam Tobin-Hochstadt 07 Aug '20

07 Aug '20

CALL FOR TUTORIAL PARTICIPATION ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming August 23 - 28, 2020 Virtual https://icfp20.sigplan.org/ Early Registration ends August 8! The 25th ACM SIGPLAN International Conference on Functional Programming will be held virtually on August 23-28, 2020. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. This year, ICFP features a wide variety of tutorials on topics related to functional programming, including design, education, tools, and more. Tutorials are available to all ICFP participants with registration. Tutorials occur before or after ICFP, co-located with the associated workshops, on August 23 or August 27-28. The schedule of ICFP Tutorials can be found at: https://icfp20.sigplan.org/track/icfp-2020-tutorials#program ICFP Early Registration ends on August 8th, and is available at: https://icfp20.sigplan.org/attending/Registration

1 0

Core optimizations affected by package provenance
by Li-yao Xia 07 Aug '20

07 Aug '20

Hello Café, I've been testing properties of some optimized Core using the inspection-testing library. Some functions appear to be optimized differently depending on whether one of the package dependencies comes from Hackage or elsewhere. As far as I can tell, the source code is identical, and the only difference is whether or not I add the path to the local package in my cabal.project. Why would a dependency be compiled differently depending on where it comes from? Any suggestions on how to troubleshoot this? To be more concrete, the relevant packages are generic-random and splitmix. The following commands should reproduce the issue: git clone https://github.com/Lysxia/generic-random git clone https://github.com/phadej/splitmix cd generic-random # With local splitmix echo "packages: . ../splitmix" > cabal.project cabal test --flags="enable-inspect" # PASS # With remote splitmix echo "packages: ." > cabal.project cabal test --flags="enable-inspect" # FAIL It would be useful to know whether anyone can reproduce this behavior or not. Cheers, Li-yao PS, link to Github issue: https://github.com/Lysxia/generic-random/issues/22

1 1

ANN: network 3.1.2.0
by Evan Borden 07 Aug '20

07 Aug '20

I'm happy to announce the release of network 3.1.2.0. https://hackage.haskell.org/package/network-3.1.2.0 This version of network includes many improvements that allow more extensibility, portability, and greater test coverage. See the log below for more information. As well version 3.1.1.0 and 3.1.1.1 have been deprecated as they contain a bug in graceful close, more details below. - Added -f devel for test cases that are known to fail. #471 <https://github.com/haskell/network/pull/471> - Improved precedence-compliant Read/Show instances. Verified via QuickCheck. #465 <https://github.com/haskell/network/pull/465> #466 <https://github.com/haskell/network/pull/466> - Removed the racing graceful close implementation to avoid issues with CLOSE_WAIT. #460 <https://github.com/haskell/network/pull/438> - Gracefully handle binding of UNIX domain sockets. #460 <https://github.com/haskell/network/pull/460> - Replace Socket type and family with extensible CInt pattern and synonyms. #459 <https://github.com/haskell/network/pull/459> - Fixed race conditions in tests. #458 <https://github.com/haskell/network/pull/458> - Removed many legacy uses of undefined. #456 <https://github.com/haskell/network/pull/456> - Defined extensible CustomSockOpt via ViewPatterns. #455 <https://github.com/haskell/network/pull/455> - Defined openSocket in terms of AddrInfo. 5b0987197fe2ed7beddd7b2096522d624e71151e <https://github.com/haskell/network/commit/5b0987197fe2ed7beddd7b2096522d624…> - Improved FreeBSD portability for Control Messages and tests #452 <https://github.com/haskell/network/pull/452> - Support sendMsg and recvMsg #433 <https://github.com/haskell/network/pull/433> #445 <https://github.com/haskell/network/pull/445> #451 <https://github.com/haskell/network/pull/451> - Added sendMsg and recvMsg APIs - Redefined SocketOption as pattern synonym - Implement total Show functions for SockAddr #441 <https://github.com/haskell/network/pull/441> - Improve portability changing u_int32_t to uint32_t. #442 <https://github.com/haskell/network/pull/442> - Removed obsolete CPP statements. d1f4ee60ce6a4a85abb79532f64d4a4e71e2b1ce <https://github.com/haskell/network/commit/d1f4ee60ce6a4a85abb79532f64d4a4e7…> - Loads of improved test coverage. cbd67cc50a37770432eb978ac8b8eb6da3664817 <https://github.com/haskell/network/commit/cbd67cc50a37770432eb978ac8b8eb6da…> fcc2d86d53a6bec793f6a979a9e8fdf7fe3f4c22 <https://github.com/haskell/network/commit/fcc2d86d53a6bec793f6a979a9e8fdf7f…> 6db96969b3e8974abbfd50a7f073baa57376fd5e <https://github.com/haskell/network/commit/6db96969b3e8974abbfd50a7f073baa57…> As always, thank you to network's contributors!

1 0

Second Call for Participation: ICFP 2020
by Sam Tobin-Hochstadt 07 Aug '20

07 Aug '20

===================================================================== Second Call for Participation ICFP 2020 25th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 23 - August 28, 2020 Online http://icfp20.sigplan.org/ Early Registration ends August 8! ==================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. Watch our new video, and Don't Stop ICFP: https://www.youtube.com/watch?v=Fte5wwnwCws Early Registration ends August 8th! Registration for students with an ACM or SIGPLAN membership is free, and anyone can apply for a fee waiver at: https://icfp20.sigplan.org/attending/Registration This year, the conference will be a virtual event. All activities will take place online. The main conference will take place from August 24-26, 2020 during two time bands. The first band will be 9AM-5:30PM New York, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 9AM-5:30PM Beijing, the following day. We've written a blog post about how conference mirroring will work for ICFP: https://blog.sigplan.org/2020/08/04/come-to-virtual-icfp/ We’re excited to announce our two invited speakers for 2020: Evan Czaplicki, covering the Elm programming language and hard lessons learned on driving adoption of new programming languages; and Audrey Tang, Haskeller and Taiwan’s Digital Minister, on how software developers can contribute to fighting the pandemic. ICFP has officially accepted 37 exciting papers, and (as a fresh experiment this year) there will also be presentations of 8 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 8th, 2020. Registration is not free, but is significantly lower than usual. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2020conf/ICFP20/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp20.sigplan.org/home * Full Schedule: https://icfp20.sigplan.org/program/program-icfp-2020 * Accepted papers: http://icfp20.sigplan.org/track/icfp-2020-papers#event-overview * JFP Talks: https://icfp20.sigplan.org/track/icfp-2020-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2020conf/ICFP20/register.php Early registration ends 8 August, 2020. * Programming contest: https://icfpcontest2020.github.io/ * Student Research Competition: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/23) * Haskell Implementors' Workshop (8/28) * Haskell Symposium (8/27-8/28) * Higher-Order Programming with Effects (8/23) * miniKanren Workshop (8/27) * ML Family Workshop (8/27) * OCaml Workshop (8/28) * Programming Languages Mentoring Workshop (8/23) * Scheme Workshop (8/28) * Type-Driven Development (8/23) ### ICFP Organizers General Chair: Stephanie Weirich (University of Pennsylvania, USA) Program Chair: Adam Chlipala (MIT, USA) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Ben Lippmeier (Ghost Locomotion, Australia) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organizer: Igor Lukanin (Kontur, Russia) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Youyou Cong (Tokyo Institute of Technology, Japan) Workshops Co-Chair: Jennifer Hackett (University of Nottingham, UK) Leonidas Lampropoulos (University of Pennsylvania, USA) Video Chair: Leif Andersen (Northeastern University, USA) Student Volunteer Co-Chair: Hanneli Tavante (McGill University, Canada) Victor Lanvin (IRIF, Université Paris Diderot, France)

1 0

stack: pandoc fails to build as dependency
by Olaf Klinke 06 Aug '20

06 Aug '20

Dear cafe, I am baffled to learn that stack does not provide builds as reproducible as advertised. I have a project that depends on pandoc. It builds fine on my Debian 9 machine. Then I check out the project on a Debian 8 machine. Downloading and building pandoc-2.7.3 with the latest stack-2.1.3 on the Debian 8 machine runs fine. Now I create a new project, using the same stack.yaml as in the pandoc-2.7.3 package, except now pandoc-2.7.3 is an extra-dep. The project's only module contains nothing but: module Test where import Text.Pandoc Building this project with the same stack results in a linker error: pandoc > Preprocessing executable 'pandoc' for pandoc-2.7.3.. pandoc > Building executable 'pandoc' for pandoc-2.7.3.. pandoc > [1 of 2] Compiling Main pandoc > [2 of 2] Compiling Paths_pandoc pandoc > Linking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/pandoc/pandoc ... pandoc > collect2: error: ld returned 1 exit status pandoc > `gcc' failed in phase `Linker'. (Exit code: 1) This seems to be independent of the LTS version (the stack.yaml in pandoc-2.7.3 says lts-13.17 although lts-13.17 contains pandoc-2.5 and pandoc-2.7.3 is available only in 14.9). Can somebody hint what I am doing wrong? Should I file a bug report? Thanks Olaf

3 3

dates...
by Gregory Guthrie 06 Aug '20

06 Aug '20

I don't understand why the Julian conversion are given relative to 2019, instead of 2020, and don't seem to actually show the date index. Must be misreading the library specs? toJulianYearAndDay :: Day<https://hackage.haskell.org/package/time-1.6/docs/Data-Time-Calendar.html#t…> -> (Integer<https://hackage.haskell.org/package/base-4.8.1.0/docs/Prelude.html#t:Integer>, Int<https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Int.html#t:Int>) convert to proleptic Julian year and day format. First element of result is year (proleptic Julian calendar), second is the day of the year, with 1 for Jan 1, and 365 toJulian :: Day<https://hackage.haskell.org/package/time-1.6/docs/Data-Time-Calendar.html#t…> -> (Integer<https://hackage.haskell.org/package/base-4.8.1.0/docs/Prelude.html#t:Integer>, Int<https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Int.html#t:Int>, Int<https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Int.html#t:Int>) Source<https://hackage.haskell.org/package/time-1.6/docs/src/Data-Time-Calendar-Ju…> convert to proleptic Julian calendar. First element of result is year, second month number (1-12), third day (1-31). ---------------------------------------------------------------------------------- ds = "1/8/2020" day = parseTimeOrError True defaultTimeLocale "%-m/%-d/%Y" ds :: UTCTime getDay = toGregorian . utctDay getDayOfYear = toJulian . utctDay getDayYear = toJulianYearAndDay. utctDay main = do print day print $ getDay day print $ getDayYear day print $ getDayOfYear day 2020-01-08 00:00:00 UTC (2020,1,8) (2019,360) (2019,12,26) And; 2020-02-08 00:00:00 UTC (2020,2,8) (2020,26) (2020,1,26) Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

2 2

Best ways to achieve throughput, for large M:N ratio of STM threads, with hot TVar updates?
by YueCompl 06 Aug '20

06 Aug '20

Hello Cafe, I'm working on an in-memory database, in Client/Server mode I just let each connected client submit remote procedure call running in its dedicated lightweight thread, modifying TVars in RAM per its business needs, then in case many clients connected concurrently and trying to insert new data, if they are triggering global index (some TVar) update, the throughput would drop drastically. I reduced the shared state to a simple int counter by TVar, got same symptom. While the parallelism feels okay when there's no hot TVar conflicting, or M is not much greater than N. As an empirical test workload, I have a `+RTS -N10` server process, it handles 10 concurrent clients okay, got ~5x of single thread throughput; but in handling 20 concurrent clients, each of the 10 CPUs can only be driven to ~10% utilization, the throughput seems even worse than single thread. More clients can even drive it thrashing without much progressing. I can understand that pure STM doesn't scale well after reading [1], and I see it suggested [7] attractive and planned future work toward that direction. But I can't find certain libraries or frameworks addressing large M over small N scenarios, [1] experimented with designated N parallelism, and [7] is rather theoretical to my empirical needs. Can you direct me to some available library implementing the methodology proposed in [7] or other ways tackling this problem? I think the most difficult one is that a transaction should commit with global indices (with possibly unique constraints) atomically updated, and rollback with any violation of constraints, i.e. transactions have to cover global states like indices. Other problems seem more trivial than this. Specifically, [7] states: > It must be emphasized that all of the mechanisms we deploy originate, in one form or another, in the database literature from the 70s and 80s. Our contribution is to adapt these techniques to software transactional memory, providing more effective solutions to important STM problems than prior proposals. I wonder any STM based library has simplified those techniques to be composed right away? I don't really want to implement those mechanisms by myself, rebuilding many wheels from scratch. Best regards, Compl [1] Comparing the performance of concurrent linked-list implementations in Haskell https://simonmar.github.io/bib/papers/concurrent-data.pdf <https://simonmar.github.io/bib/papers/concurrent-data.pdf> [7] M. Herlihy and E. Koskinen. Transactional boosting: a methodology for highly-concurrent transactional objects. In Proc. of PPoPP ’08, pages 207–216. ACM Press, 2008. https://www.cs.stevens.edu/~ejk/papers/boosting-ppopp08.pdf <https://www.cs.stevens.edu/~ejk/papers/boosting-ppopp08.pdf>

9 28

ANN: stack-2.3.3
by Emanuel Borsboom 06 Aug '20

06 Aug '20

See https://haskellstack.org/ for installation and upgrade instructions. Changes since v2.3.1 Other enhancements: * Add the stack-developer-mode flag Bug fixes: * When using the STACK_YAML env var with Docker, make the path absolute. * Fix the problem of stack repl foo:test:bar failing without a project build before that. See #5213<https://github.com/commercialhaskell/stack/issues/5213> * Fix stack sdist introducing unneded sublibrary syntax when using pvp-bounds. See #5289<https://github.com/commercialhaskell/stack/issues/5289> Thanks to all our contributors for this release: * coord.e * Dmitry Dzhus * Emanuel Borsboom * Kirill Zaborsky * Michael Snoyman

1 0

[ANN] isbn - ISBN Validation and Manipulation
by Christian Charukiewicz 30 Jul '20

30 Jul '20

Hello Haskell Cafe, I wanted to share my first ever Haskell package: isbn https://hackage.haskell.org/package/isbn The package is motivated by my need to validate ISBNs (the unique identifier associated with every book published since 1970) in a Haskell application I am building. I published isbn as a back in May but yesterday I made some improvements the API and I think it is now ready to share as v1.1.0.0. I have been using Haskell commercially for a few years, and have made several contributions to various packages, but as mentioned, this is my first time authoring and publishing a package. If anyone has any feedback, I would be happy to hear it. Thank you, Christian Charukiewicz

2 2

Re: [Haskell-cafe] STM friendly TreeMap (or similar with range scan api) ? WAS: Best ways to achieve throughput, for large M:N ratio of STM threads, with hot TVar updates?
by Peter Robinson 30 Jul '20

30 Jul '20

Hi Compl, > >+ This package provides a proof-of-concept implementation of a skip list >> in STM >> >> This has to mean something but I can't figure out yet. >> >> Dear Peter Robinson, I hope you can see this message and get in the loop >> of discussion. >> > The reason for adding this sentence was that tskiplist hasn't been optimized for production use. Later on, I wrote an implementation of a concurrent skip list with atomic operations that performs significantly better, but it's operations work in the IO monad. I'm surprised to hear that you're getting poor performance even when using the stm-container package, which I believe was meant to be used in production. A while ago, I ran some benchmarks comparing concurrent dictionary data structures (such as stm-container) under various workloads. While STMContainers.Map wasn't as fast as the concurrent-hashtable package, the results indicate that the performance doesn't degrade too much under larger workloads. You can find these benchmark results here (10^6 randomly generated insertion/deletion/lookup requests distributed among 32 threads): https://lowerbound.io/blog/bench2-32.html And some explanations about the benchmarks are here: https://lowerbound.io/blog/2019-10-24_concurrent_hash_table_performance.html One issue that I came across when implementing the tskiplist package was this: If a thread wants to insert some item into the skip list, it needs to search for the entry point by performing readTVar operations starting at the list head. So, on average, a thread will read O(log n) TVars (assuming a skip list of n items) and, if any of these O(log n) TVars are modified by a simultaneously running thread, the STM runtime will observe a (false) conflict and rerun the transaction. It's not clear to me how to resolve this issue without access to something like unreadTVar (see [1]). Best, Peter [1] UnreadTVar: Extending Haskell Software Transactional Memory for Performance (2007) by Nehir Sonmez , Cristian Perfumo , Srdjan Stipic , Adrian Cristal , Osman S. Unsal , Mateo Valero.

3 3