- Haskell-Cafe - Haskell.org

Call for Participation: BOB 2019 (March 22, Berlin)
by Matthias Fischmann 06 Jan '19

06 Jan '19

================================================================================ BOB 2019 Conference “What happens if we simply use what’s best?” March 22, 2019, Berlin http://bobkonf.de/2019/ Program: http://bobkonf.de/2019/en/program.html Registration: http://bobkonf.de/2019/en/registration.html ================================================================================ BOB is the conference for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experiences. The program features 14 talks and 8 tutorials on current topics: http://bobkonf.de/2019/en/program.html The subject range of talks includes functional programming, formal methods, event sourcing, music, advanced SQL, logic, and feeling The tutorials feature introductions to Racket, Clojure, Functional Programming, TypeScript, type-level programming, SQL indexing, probabilistic programming, and hardware. Gabriele Keller will give the keynote talk. Registration is open online: http://bobkonf.de/2019/en/registration.html NOTE: The early-bird rates expire on February 19, 2019! BOB cooperates with the RacketFest conference on the following day: https://racketfest.com/

1 0

Re: [Haskell-cafe] Consider operator fixity when deriving Show or Read
by Doaitse Swierstra 06 Jan '19

06 Jan '19

The current GHC implementation constructs Read instances out of other Read instances. In order to make this work some restictions are necessary. Given that a top-down paring strategy is used we cannot easily construct parsers for left-recursive data types. To cope with this problem, and to make sure that at least Read instances can read data written by Show instances, data is written out by Show instances with a sufficjently large number of parentheses. Unfortunately this may make reading data back extremely show. A solution for this problem is described in out Haskell 2008 Workshop paper: @inproceedings{1411296, Address = {New York, NY, USA}, Author = {Viera, Marcos and Swierstra, S. Doaitse and Lempsink, Eelco}, Booktitle = {Haskell Symposium}, Date-Added = {2009-06-06 22:24:07 +0200}, Date-Modified = {2009-06-06 22:24:07 +0200}, Doi = {http://doi.acm.org/10.1145/1411286.1411296}, Isbn = {978-1-60558-064-7}, Location = {Victoria, BC, Canada}, Pages = {63--74}, Publisher = {ACM}, Read = {Yes}, Title = {Haskell, do you read me?: constructing and composing efficient top-down parsers at runtime}, Year = {2008}, }} which I am attaching. Unfortunately the solution to solve all problems is rather involved. The code you can find in the package ChristmasTree: "ChristmasTree (Changing Haskell's Read Implementation Such That by Manipulating ASTs it Reads Expressions Efficiently) is an alternative approach of read that composes grammars instead of parsers. It reads data in linear time, while the function read has an exponential behavior in some cases of data types with infix operators.” Hope this helps answering your question, Doaitse > Op 6 jan. 2019, om 11:34 heeft Oleg Grenrus <oleg.grenrus(a)iki.fi> het volgende geschreven: > > Report says explicitly "ignoring associativity". Yet, I have written manual Show/Read to make Show of list-like data prettier: I don't know any problem with that. Would be good to know, why report is written as it is. > > - Oleg > > The result of show is a syntactically correct Haskell expression containing only constants, given the fixity declarations in force at the point where the type is declared. It contains only the constructor names defined in the data type, parentheses, and spaces. When labelled constructor fields are used, braces, commas, field names, and equal signs are also used. Parentheses are only added where needed, ignoring associativity. No line breaks are added. The result of showis readable by read if all component types are readable. (This is true for all instances defined in the Prelude but may not be true for user-defined instances.) > > Sent from my iPhone > > On 6 Jan 2019, at 3.53, Dannyu NDos <ndospark320(a)gmail.com> wrote: > >> Sorry for the mix-up. I mean associativity, not fixity! >> >> 2019년 1월 6일 (일) 오전 9:06, Dannyu NDos <ndospark320(a)gmail.com>님이 작성: >> For the following code as an example: >> >> {-# LANGUAGE TypeOperators #-} >> >> infixr 5 :. >> >> data List a = Null | a :. List a deriving (Eq, Ord, Show, Read) >> >> >> The Show instance and the Read instance are inaware of the fixity of (:.): >> >> *Main> 2 :. 3 :. Null >> 2 :. (3 :. Null) >> *Main> read "2 :. 3 :. Null" :: List Int >> *** Exception: Prelude.read: no parse >> *Main> read "2 :. (3 :. Null)" :: List Int >> 2 :. (3 :. Null) >> >> The derived instances should be: >> >> instance Show a => Show (List a) where >> showsPrec p Null = showParen (11 <= p) (showString "Null") >> showsPrec p (x :. xs) = showParen (5 <= p) (go p (x :. xs)) where >> go _ Null = showString "Null" >> go p (x :. xs) = showsPrec p x . showString " :. " . go p xs >> >> instance Read a => Read (List a) where >> readPrec = parens $ do >> Ident "Null" <- lexP >> return Null >> +++ (do >> x <- readPrec >> Symbol ":." <- lexP >> xs <- readPrec >> return (x :. xs) >> ) >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

Maybe type filtered to remove Nothing
by Damien Mattei 05 Jan '19

05 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

Ord methods too strict?
by V.Liepelt 04 Jan '19

04 Jan '19

I am surprised to find that `False <= undefined = undefined`. What justifies (<=) to be strict in both arguments? Vilem

7 15

Re: [Haskell-cafe] Ord methods too strict?
by Olaf Klinke 04 Jan '19

04 Jan '19

Information-theoretically 'compare' must be stricter than <= because is gives more information: It decides equality, which <= doesn't. Therefore compare must be strict in both arguments. What follows is an argument that there can not be a lazy implementation of <= that behaves like logical implication. We try to model <= after the logical implication operator. Order-theoretically, the binary operation (<=) should be antitone in the first and monotone in the second argument. The preceding sentence only makes sense once we define a mathematical order on the semantics of Bool. Let's declare the "logical" order False < undefined < True. I give a formal justification in Appendix A below. Arrange all nine combinations of type (Bool,Bool) in a 3x3 grid where the first dimension is descending and the second dimension is ascending in the logical order. Now we consider: (undefined,True) must map to True because (True,True) maps to True and descending in the first argument means ascending in the result. (False,undefined) must map to True because (False,False) maps to True and ascending in the second argument means ascending in the result. Further we require (True,False) mapping to False. But now we're in trouble: A function giving the above three return values requires ambiguous choice, which we don't have available in pure, sequential Haskell, q.e.d. It's the same reason why we can't have (&&) or (||) operators which behave symmetrically w.r.t. the logical order. Olaf ========== Appendix A Let R be a binary relation on a set A. The Egli-Milner-lifting of R is a binary relation on the powerset of A. Among several possible liftings, it is the one with the most pleasing properties [1, Theorem 2.12]. Identify the "undefined" value of a type A with the maximal element of the powerset of A, which expresses that "undefined" may evaluate to anything. In Haskell terms: {-# LANGUAGE Rank2Types #-} module RelationLifting where import Prelude hiding (undefined) type Relation a = a -> a -> Bool type Lifting = forall a. Relation a -> Relation [a] egliMilner :: Lifting egliMilner r xs ys = hoare && smyth where hoare = all (\x -> any (\y -> r x y) ys) xs smyth = all (\y -> any (\x -> r x y) xs) ys true, false, undefined :: [Bool] true = [True] false = [False] undefined = [False,True] RelationLifting> egliMilner (<=) false undefined True RelationLifting> egliMilner (<=) undefined true True [1] https://www.cs.le.ac.uk/people/akurz/Papers/kv-relation-lifting.pdf

2 1

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 04 Jan '19

04 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 04 Jan '19

04 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