- Haskell-Cafe - Haskell.org

conduit: consume part of input and push all other input downstream
by Qingbo Liu 08 Jan '19

08 Jan '19

Dear Cafe, I am using conduit to parse a file in a streaming fashion. In the middle of the conduit pipeline, I have a conduit that parses a value, returns the value, and then passes all other input downstream. Is there any way to express this? I looked up functions provided by the conduit and it seems that there is no such a function that provides such semantics. My conduit function looks as follows: -- | Run the given `Get` only once and push unconsumed bytes from upstream to -- downstream conduitParseOnce :: (MonadThrow m, MonadResource m) => Get a -> ConduitT BS.ByteString BS.ByteString m a conduitParseOnce g = go0 where go0 = do x <- await case x of Nothing -> undefined -- throwM SomeException Just bs -> go (runGetChunk g Nothing bs) go (Fail msg bs) = throwM (DecodeError bs msg "conduitParseOnce") go (Partial f) = await >>= maybe (go $ f mempty) (go . f) go (Done v bs) = leftover bs >> return v The downstream of this conduit will take all remaining inputs and parses them. The issue with this implementation is that the downstream will only be able to get the first chunk of data. Best Regards, Qingbo Liu

1 0

Hide internal modules but expose them for testing
by Georgi Lyubenov 07 Jan '19

07 Jan '19

Greetings, I want to have internal modules which I do not expose at all. I also want to be able to test them. This however also hides these modules from my tests. The best way I have found to work around this is to include my entire source directory in the test suite (source-dirs). This however means that I can't reuse builds that didn't include the tests. Is there some obvious and "best" solution that I am missing here? For reference I use Stack. Thanks in advance! ======= Georgi

4 3

10 PhD studentships in Nottingham
by Graham Hutton 07 Jan '19

07 Jan '19

Dear all, *** FINAL CALL -- APPLICATION DEADLINE 18 JANUARY 2019 *** The School of Computer Science at the University of Nottingham is seeking applications for 10 fully-funded PhD studentships: https://tinyurl.com/10-phds-2019 Applicants in the area of the Functional Programming Laboratory (https://tinyurl.com/fp-notts) are strongly encouraged! If you are interested in applying, please contact a potential supervisor as soon as possible (the application deadline is 18th January): Thorsten Altenkirch - constructive logic, proof assistants, homotopy type theory, category theory, lambda calculus. Venanzio Capretta - type theory, mathematical logic, corecursive structures, proof assistants, category theory, epistemic logic. Graham Hutton - functional programming, program calculation and transformation, correctness and efficiency, category theory. Henrik Nilsson - functional reactive programming, modelling and simulation, domain-specific languages, probabilistic languages. Best wishes, Graham +-----------------------------------------------------------+ 10 Fully-Funded PhD Studentships School of Computer Science University of Nottingham, UK https://tinyurl.com/10-phds-2019 Applications are invited for up to ten fully-funded PhD studentships in the School of Computer Science at the University of Nottingham, starting on 1 October 2019. The topics for the studentships are open, but should relate to one of the School’s research groups: Agents Lab; Automated Scheduling and Planning; Computer Vision Lab; Data Driven Algorithms, Systems and Design; Functional Programming Lab; Intelligent Modelling and Analysis; Uncertainty in Data and Decision Making; Mixed Reality Lab. The studentships are for a minimum of three years and include a stipend of £14,777 per year and tuition fees. They are open to students of any nationality. Applicants are normally expected to have a first-class MSc or BSc in Computer Science or a related discipline, and must obtain the support of a supervisor in the School prior to submitting their application. Initial contact with supervisors should be made at least two weeks prior to the closing date for applications. Informal enquiries may be addressed to SS-PGR-JC(a)nottingham.ac.uk. To apply, please submit the following items by email to: Christine.Fletcher(a)nottingham.ac.uk: (1) a brief covering letter that describes your reasons for wishing to pursue a PhD, your proposed research area and topic, and the name of the potential supervisor whose support you have already secured; (2) a copy of your CV, including your actual or expected degree classes, and results of all University examinations; (3) an extended example of your technical writing, such as a project report or dissertation; (4) contact details for two academic referees. Closing date for applications: Friday 18 January 2019 +-----------------------------------------------------------+ 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

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

05 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