January 2019 - Haskell-Cafe

RFC: in haddock, collapse instances by default
by Li-yao Xia 04 Jan '19

04 Jan '19

Hello Café, I would like to propose making haddock keep instance lists collapsed by default. Some discussion is in order since it would significantly affect the documentation of many packages on Hackage. Feel free to reply here or on the related Github thread: https://github.com/haskell/haddock/issues/698 1. Instance lists take a lot of screen estate For a motivating example, I can point to the Prelude we all love. https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html We are immediately welcomed by half a page of instances of Bool, which is not quite bad, but classes have the most impressive instance lists, as you may see when you reach Eq. Many packages, even commonly used ones, have the same issue. For an extreme example, see the scrollbar jump when you fold the instance list of Apply in singletons. https://hackage.haskell.org/package/singletons-2.5.1/docs/Data-Singletons.h… 2. Current workarounds They can be collapsed manually one by one, and we can jump to the middle of a module with the table of contents, but scrolling up from the bottom of an instance list is still a chore. Of course, instance lists also contain quite important information. Would it become too easy to miss if it were hidden by default? Would a more fine-grained alternative be better? Regards, Li-yao

9 9

Left and right monadic folds
by Michail Pevnev 03 Jan '19

03 Jan '19

Hello everyone. Recently I've run into a situation where a monadic fold seems like an interesting option. However, I'm not particularly sure how to choose which fold - left or right - to use. For non-monadic folds the rule of thumb is 'avoid foldl, use foldr for infinite things and foldl' for performance'. What are the guidelines for the monadic ones? The fact that 'foldlM' is implemented (in base-4.12.0-0) using 'foldr' and 'foldrM' uses 'foldl' (also, non-strict foldl, which is worrying) adds somewhat to my confusion. I've played a bit with folding Eithers, and foldlM seems to work somewhat intuitively (breaks on the first Left, as is usual for Either), and also accepts infinite lists (which makes sense, given it's a foldr): import Data.Foldable main :: IO () main = do print $ sumNonNegative $ [1, 2, -4] ++ [5..] sumNonNegative :: [Int] -> Either String Int sumNonNegative = foldlM foo 0 foo :: Int -> Int -> Either String Int foo acc x | x >= 0 = Right $ x + acc | otherwise = Left $ "Negative number: " ++ show x This prints out "Negative number: -4". Odd things begin when I edit the above to use foldrM. It doesn't terminate on an infinite list, which is expected from a disguised foldl. But given several negative numbers in the input, it prints out the last one, seemingly turning the usual behaviour of Either on its head. It seems its foldl heritage results in applying side-effects (in case of Either, erroring out with a Left) in reverse order. Do I get this right and is this the general behaviour of foldrM for any monad? -- Michail.

2 1

Call for papers: DBPL 2019
by Alvin Cheung 03 Jan '19

03 Jan '19

The 17th International Symposium on Database Programming Languages https://pldi19.sigplan.org/track/dbpl-2019-papers Phoenix, Arizona, USA June 23, 2019 hosted as part of PLDI 2019 Call for Papers For over 25 years, DBPL has established itself as the principal venue for publishing and discussing new ideas at the intersection of databases and programming languages. Many key contributions in query languages for object-oriented data, persistent databases, nested relational data, and semistructured data, as well as fundamental ideas in types for query languages, were first announced at DBPL. Today, this creative research area is broadening into a subfield of data-centric computation, currently scattered among a range of venues. DBPL is an established destination for such new ideas and solicits submissions from researchers in databases, programming languages or any other community interested in the design, implementation or foundations of data-centric computation. Scope ----- DBPL solicits practical and theoretical papers in all topics at the intersection of databases and programming languages. Papers emphasizing new topics or emerging areas are especially welcome. Suggested, but not exclusive, topics of interest for submissions include: - Compiling Query Languages to Modern Hardware - Data-Centric Programming Abstractions, Comprehensions, Monads - Data Integration, Exchange, and Interoperability - Data Synchronization and Bidirectional Transformations - Declarative Data Centers (e.g., distributed query processing, serverless computing platforms, social computing platforms, etc) - Emerging and Nontraditional Data Models - Language-Based Security in Data Management - Language-Integrated Query Mechanisms - Managing Uncertain and Imprecise Information - Metaprogramming and Heterogeneous Staged Computation - Programming Language Support for Data-Centric Programming (e.g., databases, web programming, machine learning, etc) - Query Compilation and In-memory Databases - Query Language Design and Implementation - Query Transformation and Optimization - Schema Mapping and Metadata Management - Semantics and Verification of Database Systems - Stream Data Processing and Query Languages - Type and Effect Systems for Data-Centric Programming Author Guidelines ----------------- Prospective authors are invited to submit full papers in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Submissions should be no more than 10 pages long, excluding references, in the two-column ACM proceedings format, following PLDI’s formatting requirements (https://pldi19.sigplan.org/track/pldi-2019-papers#Call-for-Papers) Each submission should begin with a succinct statement of the problem and a summary of the main results. Authors may provide more details to substantiate the main claims of the paper by including a clearly marked appendix at the end of the submission, which is not included in the page limit and is read at the discretion of the committee. At least one author of each accepted paper must attend the symposium to present their work. Short papers of at most 4 pages (same format as long papers) describing work in progress, demos, research challenges or visions are also welcome. Accepted short papers may be included or excluded from the formal proceedings, whichever the author(s) prefer. Full and short papers are both due on the deadline, February 15, 2019. Instructions on how to submit will be posted on the symposium website noted above. Review is single-blind, so authors do not need to anonymize their submissions. PC submissions are allowed, except for the co-chairs. Important Dates --------------- - Paper Submission: February 15, 2019 - Notification: March 29, 2019 - Final versions due: April 16, 2019 - Symposium: June 23, 2019 Proceedings ----------- Accepted papers will appear as part of the PLDI Proceedings for DBPL 2019. Program Committee ----------------- *Program Co-Chairs* Alvin Cheung, University of Washington Kim Nguyễn, Université Paris-Sud *Program Committee* William Cook, University of Texas at Austin Vasiliki Kalavri, ETH Harshad Kasture, Oracle Oleg Kiselyov, University of Tsukuba Sam Lindley, University of Edinburgh Tiark Rompf, Purdue University Stefanie Scherzinger, OTH Regensberg Amir Shaikhha, EPFL / University of Oxford Avi Shinnar, IBM Guido Wachsmuth, Oracle Melanie Wu, Pomona College History ------- The 17th Symposium on Data Base Programming Languages (DBPL 2019) continues the tradition of excellence initiated by its predecessors in Roscoff, Finistere (1987), Salishan, Oregon (1989), Nafplion, Argolida (1991), Manhattan, New York (1993), Gubbio, Umbria (1995), Estes Park, Colorado (1997), Kinloch Rannoch, Scotland (1999), Marino, Rome (2001), Potsdam, Germany (2003), Trondheim, Norway (2005), Vienna, Austria (2007), Lyon, France (2009), Seattle, Washington (2011), Riva del Garda, Italy (2013), Pittsburgh, Pennsylvania (2015), Munich, Germany (2017). DBPL was affiliated with VLDB from 1999-2013 and in 2017. In 2015, it is affiliated with SPLASH for the first time and in 2019, it is affiliated with PLDI for the first time.

1 0

Concordium is hiring
by Bas Spitters 03 Jan '19

03 Jan '19

Concordium is the first ID/KYC ready blockchain network. Concordium focuses strongly on software quality and uses languages such as haskell, rust and Coq. There are a number of positions available at the offices in either Aarhus, Zurich, London and Marbella. In exceptional cases is off-site work possible. There is a preference for people with a relevant PhD or master's degree. https://www.concordium.com/careers/ In particular, the Concordium Aarhus office has a strong background in functional programming and type theory, and is looking to strengthen this team. There is a tight collaboration with the scientists at the Concordium Blockchain Research Center at Aarhus University. The center is also advertising several PhD and postdoc positions. https://www.iacr.org/jobs/#1717

1 0

Maybe type filtered
by Damien Mattei 03 Jan '19

03 Jan '19

i had filtered a [Maybe Text] type to remove Nothing from the list and now i want to put the result in a [Text] type but the compiler complains about the incompatible type : (bd_rows_WDS :: [Only (Maybe Text)]) <- query conn qry_head_WDS (Only (name::String)) -- remove the records having N°BD NULL let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS Prelude> :load UpdateSidonie [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) UpdateSidonie.hs:282:33: error: • Couldn't match type ‘Maybe Text’ with ‘Text’ Expected type: [Only Text] Actual type: [Only (Maybe Text)] • In the expression: Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In a pattern binding: fltWDS :: [Only Text] = Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In the expression: do conn <- connect defaultConnectInfo {connectHost = "moita", connectUser = "mattei", connectPassword = "sidonie2", connectDatabase = "sidonie"} (rows :: [(Text, Double)]) <- query_ conn "SELECT Nom,distance FROM AngularDistance WHERE distance > 0.000278" (names :: [Only Text]) <- query_ conn "SELECT Nom FROM AngularDistance WHERE distance > 0.000278" let resLstNames = Prelude.map fromOnly names .... | 282 | let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Failed, no modules loaded. how can id do the type conversion,now i'm sure there is no more Nothing values?

3 3

remove Maybe
by Damien Mattei 02 Jan '19

02 Jan '19

i had filtered a [Maybe Text] type to remove Nothing from the list and now i want to put the result in a [Text] type but the compiler complains about the incompatible type : (bd_rows_WDS :: [Only (Maybe Text)]) <- query conn qry_head_WDS (Only (name::String)) -- remove the records having N°BD NULL let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS Prelude> :load UpdateSidonie [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) UpdateSidonie.hs:282:33: error: • Couldn't match type ‘Maybe Text’ with ‘Text’ Expected type: [Only Text] Actual type: [Only (Maybe Text)] • In the expression: Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In a pattern binding: fltWDS :: [Only Text] = Prelude.filter (\ (Only a) -> case a of Nothing -> False Just a -> True) bd_rows_WDS In the expression: do conn <- connect defaultConnectInfo {connectHost = "moita", connectUser = "mattei", connectPassword = "sidonie2", connectDatabase = "sidonie"} (rows :: [(Text, Double)]) <- query_ conn "SELECT Nom,distance FROM AngularDistance WHERE distance > 0.000278" (names :: [Only Text]) <- query_ conn "SELECT Nom FROM AngularDistance WHERE distance > 0.000278" let resLstNames = Prelude.map fromOnly names .... | 282 | let fltWDS :: [Only Text] = Prelude.filter (\(Only a) -> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Failed, no modules loaded. how can id do the type conversion,now i'm sure there is no more Nothing values?

2 1

MVar considered harmful
by Станислав Черничкин 01 Jan '19

01 Jan '19

Recently I had an interesting discussion on MVars with cats-effect library designers. Cats-effect brings MVar synchronization primitive along with other IO stuff to the Scala programming language. I tried to persuade them to include some Control.Concurrent.MVar’s functions to the library but has failed completely. Moreover, now I think that MVar is a poor choice for basic synchronization primitive. Your may find discussion here https://github.com/typelevel/cats-effect/issues/451 and event try to advocate, tl;dr. Anyway, what is so wrong with MVar? 1. It’s complex. Each MVar has 2 state transitions, each may block. 2. It does not play well in presence of asynchronous exceptions. More specifically, `take` and `put` operations should be balanced (each `take` must be followed by `put`) this force programmer to mask asynchronous exceptions during the MVar acquisition and since `take` function may block, this will delay task cancelation. Well, you may argue what the `takeMVar` function is actually interruptible, but I’m going to show an easier approach which renders interpretability magic unnecessary. What could be the sensible alternative? Guy from the cats-effect suggested me IVar + atomic reference (IORef). This pattern separates concern of blocking (synchronization) from the atomic mutation. So everything can be represented as atomic reference with IVar inside. Just look at this beautiful mutex implementation https://github.com/ovotech/fs2-kafka/blob/master/src/main/scala/fs2/kafka/i… (By ”beautiful” I mean approach itself of course, but not the Scala’s syntax. Scala is one of most ugliest girls after C++ I was forced to date with by my employer for money. Thankfully he didn’t force me to do the same things with her grandma Java). For people who don’t read Scala, the approach is fairly simple. Each thread which want to touch mutex, will create IVar, atomically swap it in the IORef masked (note, that IORef’s operations non-blocking), unmask and wait for previous become available IVar *unmasked*. Then it will either perform it’s operations or fail due to the interruption or exception and trigger newly installed IVar anyway. It just works. Without any «interruptible» magic. So, which benefits can we get? 1. Simpler implementation of basic primitives. Obliviously IORef is fairly simple. IVar is also mind be simpler than MVar, and possibly faster (just “possibly”, I don’t know how it’s implemented, but I guess lesser state transitions implies less logic). 2. Simplified deadlock analysis. Really, we have only IVar with only one state transition and only one potentially blocking operation. 3. Magicless support of interruptions. We don’t need to separate mask/uninterruptibleMask anymore, because all updates are non-blocking, and all waits are unmasked.

10 15