August 2017 - Haskell-Cafe

GHC fails to fuse [1 .. 30000000 :: Double] but fuses fromIntegral <$> [1 :: Int .. 30000000]?
by Mateusz Kowalczyk 24 Aug '17

24 Aug '17

Hi, I had few minutes timeout waiting for CI today and I stumbled upon [1]. This is a many years old question and the optimal solution given there was using Vector. I thought that for such a problem it should not be necessary at all. Indeed I wrote `mean :: [Int] -> Int` and got a much faster solution. However the original signature was `mean :: [Double] -> Int`. After trivial changes (change couple of places to Double and add a single fromIntegral) I expected the same result: after all, code is nearly exactly the same. However to my disappointment, the code in question was much slower than the vector solution: how could this be? Looking in Core, I saw that GHC was not getting rid of [Double] like it was with [Int]. I was able to convince GHC to go back to fusing the list into the worker with a `map fromIntegral` but I am unhappy: why is this needed? I don't understand why GHC would not decide to fuse the initial attempt. Honestly it seems like a bug to me. What are your thoughts? For reference here is the core with fromIntegral: as expected, GHC fuses the list and inserts int2Double# as it's generating it: ``` Main.$wgo = \ (w_s5xT :: GHC.Prim.Int#) (ww_s5xX :: GHC.Prim.Int#) (ww1_s5xY :: GHC.Prim.Double#) -> case w_s5xT of wild_Xz { __DEFAULT -> Main.$wgo (GHC.Prim.+# wild_Xz 1#) (GHC.Prim.+# ww_s5xX 1#) (GHC.Prim.+## ww1_s5xY (GHC.Prim.int2Double# wild_Xz)); 30000000# -> (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) } ``` Contrast this with version that's commented out in [2]: ``` Main.$wgo = \ (w_s5vE :: [Double]) (ww_s5vI :: GHC.Prim.Int#) (ww1_s5vJ :: GHC.Prim.Double#) -> case w_s5vE of _ [Occ=Dead] { [] -> (# ww_s5vI, ww1_s5vJ #); : y_a3dU ys_a3dV -> case y_a3dU of _ [Occ=Dead] { GHC.Types.D# y1_a3dG -> Main.$wgo ys_a3dV (GHC.Prim.+# ww_s5vI 1#) (GHC.Prim.+## ww1_s5vJ y1_a3dG) } } … case Main.$wgo Main.main3 0# 0.0## … Main.main3 = GHC.Real.numericEnumFromTo @ Double GHC.Classes.$fOrdDouble GHC.Float.$fFractionalDouble Main.main5 Main.main4 … Main.main4 = GHC.Types.D# 3.0e7## … Main.main5 = GHC.Types.D# 1.0## ``` Why? There should be nothing stopping it from doing ``` Main.$wgo = \ (w_s5xT :: GHC.Prim.Double#) (ww_s5xX :: GHC.Prim.Int#) (ww1_s5xY :: GHC.Prim.Double#) -> case w_s5xT of wild_Xz { __DEFAULT -> Main.$wgo (GHC.Prim.+# wild_Xz 1#) (GHC.Prim.+# ww_s5xX 1#) (GHC.Prim.+## ww1_s5xY wild_Xz); 3.0e7## -> (# GHC.Prim.+# ww_s5xX 1#, GHC.Prim.+## ww1_s5xY 3.0e7## #) ``` Perhaps it's afraid to make the pattern match on a floating point number? Insights welcome. [1]: https://stackoverflow.com/questions/3300995/computing-the-mean-of-a-list-ef… [2]: https://stackoverflow.com/a/45840148/1432740 -- Mateusz K.

3 3

Managing a sum type with a lot of constructors
by Adam Flott 24 Aug '17

24 Aug '17

I have a sum type with a lot of constructors and I'm not sure how to represent the type with maintainability in mind. For example, data A = A1 | A2 Int | A3 Text Int32 Bool | ... | A100 Bool Every inner type is concrete. There are 100+ constructors with no sign of ever getting reduced. What technique would you recommend to keep the sum type approach but not having to define them all in one spot? I'm thinking 1 inner type + 1 function to construct per file (if that's possible).

3 3

[ANN] HSvm: Haskell bindings to libsvm library
by Pavel Ryzhov 24 Aug '17

24 Aug '17

Hi all, I am happy to announce the new version of HSvm package: http://hackage.haskell.org/package/HSvm The changelog is: 1. Upgraded to libsvm 3.22. 2. Compatibility with GHC 8.0.2 and GHC 8.2.1. 3. Fixed few bugs in marshaling of C structures. 4. Code cleanup. 5. Documentation is improved. HSvm sources are now available on GitHub: https://github.com/paulrzcz/HSvm The package is also available at Stackage Nightly from 2017-08-17: https://www.stackage.org/nightly-2017-08-17/package/HSvm-0.1.0.3.22 Thanks to Paolo Losi for package and cooperation! Cheers, Pavel

1 0

ANN: Compose :: Melbourne Conference and Unconference [Melbourne, Australia - August 28 & 29]
by Lyndon Maydwell 24 Aug '17

24 Aug '17

Since I don't believe I've updated Haskell Cafe since this year's CFP, on behalf of the Melbourne Committee I'm sending a last-minute reminder that Compose :: Conference Melbourne is running this Monday and Tuesday the 28th and 29th! All information is available online at http://www.composeconference.org/ Tickets are on sale for Day-One on Eventbrite: https://www. eventbrite.com/e/compose-melbourne-2017-tickets-34612742645 Programme: http://www.composeconference.org/2017-melbourne/day-one-program/ The second day (unconference) is free for all and will feature workshops, talks, and many other organised and disorganised activities! Unconference Information: http://www.composeconference.org/2017- melbourne/unconference/ Follow the Melbourne event on Twitter: https://twitter.com/ComposeMelb About Compose and Compose :: Melbourne Compose is a conference for functional programmers, focused on technologies such as Haskell, Scala, Clojure, OCaml, F#, SML and others. Functional programming has been taken up widely, by industry and hobbyists alike. For many of us it has renewed our belief that code should be beautiful, and that programming can be as enjoyable as it is practical. Compose is about bringing together functional programmers of all levels of skill and experience — from technical leads to novices, and from long-time hackers to students just getting started. Our experiences have shown that the theoretical can be put into practice with great success, and that topics once considered “advanced” can be made understandable and spread widely. For example, type systems, often considered complex, can simplify our lives by teaching compilers to do some of our reasoning for us. Compose Conference began in New York in 2015. Warm Regards, - Lyndon

1 0

[ANN] tasty-hedgehog: Adds support for the hedgehog property-based testing library to the tasty testing framework
by David Laing 24 Aug '17

24 Aug '17

Hi, I'm happy to announce tasty-hedgehog: https://hackage.haskell.org/package/tasty-hedgehog They are two great flavours that (now) work together, so I hope it's useful to many of you. There's an example of usage in the README on the GitHub page: https://github.com/qfpl/tasty-hedgehog Cheers, Dave

1 0

How to split (or not split) modules
by Clinton Mead 23 Aug '17

23 Aug '17

Given that one can write modules that just do reexports to control namespaces, it seems to me you've got a lot of flexibility about how you organise your actual code into modules. As long as mutually recursive functions are in the same module and instances are not orphan, you can go from the one extreme of placing all the code on one module to the other extreme of placing each function in a separate module. I believe any performance concerns regarding inlining can be addressed with explicit inline annotations. I can see the point of not having non exported functions in their own module, because to do so would mean producing extra interface code which is never directly used by clients. But other than the concerns mentioned above, I can't really work out whether to have all my code for a package in one module and split it with re-export modules, or have it in lots of little modules and combine it with re-export modules. Any guidance with the pros/cons of both approaches would be appreciated.

1 0

Fwd: Re: 123
by Dmitriy Matrosov 23 Aug '17

23 Aug '17

And even sent the answer not to the list.. Huh. -------- Forwarded Message -------- Oops, i forgot to change the subject. Sorry! On 08/16/2017 09:01 PM, Jack Henahan wrote: > > Some mostly unrelated thoughts: > > An instance head has the form `T a_1 ... a_n`, and the constraint can only > apply to the `a_i`s. Consider the Show instance for > pairs. > > instance (Show a, Show b) => Show (a, b) -- Show ((,) a b) > > The constraints only act on the parameters of the type. > > It looks like you're taking the constraint to mean "whenever I have a Showable > `f String`, this is how to define a Show instance", but a constraint > actually means "use this rule to make a Show instance for any `A f`, and > it is an error if a Show instance for `f String` is not in scope". > > In the second error, you are making the strong claim that your Show > instance for `A f` holds for any `f` and `a`. Even if you could trick > the compiler into allowing that, I don't think it would actually express > the constraint that you want it to. > > Is there something a Show instance gets you that a pretty-print function wouldn't? Well, the `Show` was just an example. And examples with `A` was just a simplified versions, but perhaps oversimplified and hiding original intention. > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE StandaloneDeriving #-} > > import Control.Applicative > import Data.Monoid > import Data.Typeable I want to have a type with many records: > data Volume t = Volume > { _volName :: t String > , _volSize :: t Int > } > > showVolume :: (Show (t String), Show (t Int)) => Volume t -> String > showVolume x = "Volume " ++ show (_volName x) ++ ", " ++ show (_volSize x) with instances parametrized by some other type. E.g. i want to define a `Monoid` based on that other type properties: > instance Alternative t => Monoid (Volume t) where > mempty = Volume {_volName = empty, _volSize = empty} > x `mappend` y = Volume > { _volName = _volName x <|> _volName y > , _volSize = _volSize x <|> _volSize y > } and i may use this like > v1 :: Alternative t => Volume t > v1 = Volume {_volName = pure "vol1", _volSize = empty} > v2 :: Alternative t => Volume t > v2 = Volume {_volName = pure "vol2", _volSize = pure 200} *Main> showVolume (v1 <> v2 :: Volume Maybe) "Volume Just \"vol1\", Just 200" *Main> showVolume (v1 <> v2 :: Volume []) "Volume [\"vol1\",\"vol2\"], [200]" But then i want to define a GADT, which has different behaviors depending on argument type. So different records, depending on their type, will behave differently. > data Config a where > Empty :: Config a > Name :: Last String -> Config String > Size :: Num a => Sum a -> Config a > deriving instance Show a => Show (Config a) > instance Monoid (Config a) where > mempty = Empty > (Name x) `mappend` (Name y) = Name (x `mappend` y) > (Size x) `mappend` (Size y) = Size (x `mappend` y) > x `mappend` Empty = x > Empty `mappend` y = y but i can't even define a `Functor` instance for this type, because `case` branches have different type and `Functor` laws won't hold.. Hm.. instance Functor Config where fmap f Empty = Empty --fmap f (Name s) = case cast f of -- Just g -> case (g s) of -- Just s' -> Name s' -- _ -> Empty -- Nothing -> Empty The other problem is with instances for classes requiring type of kind `*`. I'll end up with what i've asked before: instance (Show a, Show (t a)) => Show (Volume t) where Well, i didn't write that before asking, so i realize all these problems only now (i even forgot to change the subject, what else to say?). And now i don't even sure what the proper subject should be. So thanks and never mind, i need to try more to figure out what to ask. > > Dmitriy Matrosov <sgf.dma(a)gmail.com> writes: > >> Hi. >> >> Is there a way to avoid `UndecidableInstances` in following code: >> >> data A f = A {_a1 :: f String} >> >> instance Show (f String) => Show (A f) where >> >> it does not compile with >> >> 1.hs:4:10: error: >> • The constraint ‘Show (f String)’ >> is no smaller than the instance head >> (Use UndecidableInstances to permit this) >> • In the instance declaration for ‘Show (A f)’ >> >> Though, initially, this was >> >> {-# LANGUAGE RankNTypes #-} >> >> data A f = A {_a1 :: f String} >> >> instance forall f a. Show (f a) => Show (A f) where >> >> which also does not compile with >> >> 1.hs:5:10: error: >> • Variable ‘a’ occurs more often >> in the constraint ‘Show (f a)’ than in the instance head >> (Use UndecidableInstances to permit this) >> • In the instance declaration for ‘Show (A f)’ >> >> The error is different and i don't sure, that this two cases are related. >> >> I want these instances to make a type with many records parametrized by >> `Alternative` type, e.g. >> >> data Volume t = Volume >> { _volName :: t Name >> , _volSize :: t Size >> , _volPath :: t Path >> , _pool :: t Pool >> } >> >> When i try to make instances, which require `*` type, i will end with >> above cases. > > > -- > Jack >

2 2

Experience Report (and [Hiring])
by David Turner 23 Aug '17

23 Aug '17

Hi all, In answer to @snoyberg's call to action a few months back ( https://www.snoyman.com/blog/2017/04/haskell-success-stories) I have written up an experience report and survey results from Tracsis where I currently work: https://davecturner.github.io/2017/08/21/haskell-experience.html Also if you are interested in developer jobs in sunny Leeds and fancy joining our growing team of Haskell developers then there are links in the post with contact information and more details. We're hiring at all levels from fresh graduates up to a new Principal Developer. Please get in touch with me and/or Andrew Handley (CCd) if you'd like to ask any questions. Cheers, David

1 0

Haskell - convert postfix expression to binary tree
by Martin Studna 21 Aug '17

21 Aug '17

Hello, I am trying to convert postfix expression to binary tree. My function takes as argument a list of tokens (strings). Everytime I give the function any input, debugger writes a message: Non-exhaustive patterns in function "add". My idea was: read a token after token and determine, if it is an operator or an operand. If it is operand, don't save any node to the tree and store the number to the stack. Otherwise I create a node with an operator, pop symbols from stack, set them as children of new node and push the operator to stack. If the list of strings is empty, functions print the binary tree. Would someone explain to me, why the function gives non-exhaustive patterns error and how can I fix the function? data Tree = Leaf String | Empty | Node Tree String Tree deriving (Show) add :: Tree -> [String] -> [Tree] -> Tree add (Node l v p) [] stack = (Node l v p) add Empty (x:xs) [] | x `elem` ["*","-","+"] = add (Leaf x) xs [Leaf x] | otherwise = add Empty xs [Leaf x] add Empty (x:xs) (a:b:bs) | x `elem` ["*","-","+"] = add (Node b x a) xs (Leaf x:a:b:bs) | otherwise = add Empty xs (Leaf x:a:b:bs) add (Leaf x) token (a:b:bs) | x `elem` ["*","-","+"] = add (Node b x a) token (Leaf x:bs) | otherwise = Leaf x add (Node l v p) (x:xs) (a:b:bs) | x `elem` ["*","-","+"] = add (Node b x a) xs (Leaf x:bs) | otherwise = add (Node l v p) xs (Leaf x:a:b:bs) parse :: String -> Tree parse input = add Empty (words (toPostfix input)) []

2 1

[ANN] arrowp-qq: an arrowp refresh
by Jose Iborra López 21 Aug '17

21 Aug '17

Dear all, In case anyone finds it useful, there is a new version of arrowp in Hackage that improves the original with a much needed coat of fresh paint. Notable features include a new parser based on haskell-src-exts, a quasi quoter for arrow syntax, and improved desugaring for static choices. https://github.com/pepeiborra/arrowp <https://github.com/pepeiborra/arrowp> The package is in Hackage as **arrowp-qq** due to the impossibility to contact with Ross Paterson (Ross, if you are reading this, please send email!). https://hackage.haskell.org/package/arrowp-qq <https://hackage.haskell.org/package/arrowp-qq> For those of you reading this and wondering why would you want to use a preprocessor for something that GHC can already do, the short answer is that you probably don’t. Using the `proc` quasi quoter --------------------------- ``` addA :: Arrow a => a b Int -> a b Int -> a b Int addA f g = [proc| x -> do y <- f -< x z <- g -< x returnA -< y + z |] ``` Comparison with **arrowp** ----------------------- **arrowp-qq** extends the original **arrowp** in three dimensions: 1. It replaces the `haskell-src` based parser with one based on `haskell-src-exts`, which handles most of GHC 8.0.2 Haskell syntax. 2. It provides not only a preprocessor but also a quasiquoter, which is a better option in certain cases. 3. It extends the desugaring to handle static conditional expressions (currently only if-then-else). Example: ``` proc inputs -> do results <- processor -< inputs if outputResultsArg then outputSink -< results else returnA -< () returnA -< results ``` The standard **arrowp** (and GHC) desugaring for this code is: ``` = ((processor >>> arr (\ results -> (results, results))) >>> (first (arr (\ results -> if outputResultsArg then Left results else Right ()) >>> (outputSink ||| returnA)) >>> arr (\ (_, results) -> results))) ``` This requires an `ArrowChoice`, but there is a more efficient desugaring which performs the choice at compile time and thus an `Arrow` suffices: ``` ((processor >>> arr (\ results -> (results, results))) >>> (first (if outputResultsArg then outputSink else arr (\ results -> ())) >>> arr (\ (_, results) -> results))) ``` Comparison with **GHC** ----------------------- The GHC desugarer does not do a very good job of minimizing the number of `first` calls inserted. In certain `Arrow` instances, this can have a material effect on performance. Example: ``` trivial = proc inputs -> do chunked <- chunk -< inputs results <- process -< chunked returnA -< results ``` This code ought to desugar to a chain of arrows, and indeed, both arrowp and arrowp-qq desugar this to: ``` trivial = chunk >>> process ``` However GHC will produce (approximately) the following code: ``` arr(\inputs -> (inputs,inputs)) >>> first chunk >>> first process >>> arr fst ``` Thanks, Jose Iborra

1 0