March 2017 - Haskell-Cafe

Ideas for Haskell Summer of Code
by Niki Vazou 17 Mar '17

17 Mar '17

Hello, As a preparation for the 2017 edition of Haskell Summer of Code, we are crowdsourcing project ideas. Compiler optimizations, new libraries, desired features, or any other ideas you would like to see in the Haskell ecosystem. You can submit tickets to the Haskell Summer of Code Ideas page: https://ghc.haskell.org/trac/summer-of-code/report/1 Alternatively, you can tell us your SoC idea by responding to this thread (and I can generate the ticket). Best, Niki

3 2

How can I use “cabal repl” without base
by Adam Steen 17 Mar '17

17 Mar '17

Hi How can I use cabal repl (ghci) without base? The following contrived example shows the error -- minimal.hsmodule Minimal where myId :: a -> a myId x = x and -- minimal.cabal name: minimal version: 0.0.1 build-type: Simple cabal-version: >= 1.10 library exposed-modules: Minimal --build-depends: base default-language: Haskell2010 default-extensions: NoImplicitPrelude cabal build succeeds $ cabal build Building minimal-0.0.1... Preprocessing library minimal-0.0.1...[1 of 1] Compiling Minimal ( Minimal.hs, dist\build\Minimal.o ) but cabal repl fails $ cabal repl Preprocessing library minimal-0.0.1... GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help <interactive>:1:6: error: Not in scope: `System.IO.hSetBuffering' No module named `System.IO' is imported. <interactive>:1:30: error: Not in scope: `System.IO.stdin' No module named `System.IO' is imported. <interactive>:1:46: error: Not in scope: data constructor `System.IO.NoBuffering' No module named `System.IO' is imported. <interactive>:1:70: error: Not in scope: `System.IO.hSetBuffering' No module named `System.IO' is imported. <interactive>:1:94: error: Not in scope: `System.IO.stdout' No module named `System.IO' is imported. <interactive>:1:111: error: Not in scope: data constructor `System.IO.NoBuffering' No module named `System.IO' is imported. <interactive>:1:135: error: Not in scope: `System.IO.hSetBuffering' No module named `System.IO' is imported. <interactive>:1:159: error: Not in scope: `System.IO.stderr' No module named `System.IO' is imported. <interactive>:1:176: error: Not in scope: data constructor `System.IO.NoBuffering' No module named `System.IO' is imported. if i restore "build-depends: base" if works as expected. $ cabal repl Preprocessing library minimal-0.0.1... GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help[1 of 1] Compiling Minimal ( Minimal.hs, interpreted ) Ok, modules loaded: Minimal.*Minimal> i know just keeping "build-depends: base" will make it work, but thats not what i am asking. Note: this also applies for stack Cheers Adam ps this is cross posted from stackoverflow <http://stackoverflow.com/q/42823547/415681>

2 1

Re: [Haskell-cafe] To [] Or Not To []
by Olaf Klinke 17 Mar '17

17 Mar '17

Johannes, Thanks for writing this. Actually, your negative abstract turns out to be for a quite positive article. List are like iterators, that's the essence, and as long as you are iterating, it's fine to use []. The prominence of singly linked lists in Haskell has tought me to write my data processing programs in a streaming style. To think about what data must be held in memory (use Maps or whatever for this) and read the other data in as a list. I'd be interested whether there is a way to check which of my lists in the source code the compiler managed to "deforest" away. Which intermediate files should I look at? What are the tools to inspect? Olaf

10 11

amortized time and space for set operations
by Michael Litchard 16 Mar '17

16 Mar '17

What's the best way to calculate the amortized time and space complexity for the operations in "Implementing Sets Efficiently in a Functional Language". http://groups.csail.mit.edu/mac/users/adams/BB/92-10.ps

1 0

Package Management with Stack?
by Jun Inoue 16 Mar '17

16 Mar '17

I've gotten fed up with Cabal+Hackage build errors and I want a more stable way to manage Haskell packages. I'm NOT trying to build a Haskell project of my own, but I just want a system-wide (or at least user-wide) installation of GHC "with batteries", along with some Haskell programs that other people have written. I need xmonad installed somewhere on my $PATH and I need lens available with :m+ when I fire up ghci. I do NOT want a bunch of sandboxes scattered throughout my file system, some of which have these things installed while others don't. I was hoping Stack+Stackage would fit that bill, but going through the instructions on https://haskell-lang.org/get-started, it seems that stack is meant really for setting up sandboxes for particular projects. When I tried using it as a system-wide (or rather, user-wide) package manager, it fails. For instance, as suggested on that page, I created /tmp/HelloWorld.hs and type $ stack HelloWorld.hs which seemed to successfully download the lts-8.4 build plan and ghc-nopie-8.0.2. So far so good. But then when I typed $ stack install xmonad-contrib it said Error: While constructing the build plan, the following exceptions were encountered: In the dependencies for xmonad-contrib-0.13: X11-xft must match >=0.2, but the stack configuration has no specified version (latest applicable is 0.3.1) Recommended action: try adding the following to your extra-deps in /home/jun/.stack/global-project/stack.yaml: - X11-xft-0.3.1 You may also want to try the 'stack solver' command Plan construction failed. I've tried going down the "stack solver" rabbit hole, to no avail; it just tells me I need to register a directory containing a .cabal file. IIUC, that's a directory containing some project I'm developing? But I have no such project! (At the moment.) Am I fundamentally misunderstanding how stack is supposed to be used? Is stack usable as a package manager in the way cabal sort of was, and in the way apt-get or emerge can be used? If not, what do people recommend I use for that purpose? Nix? Or, perhaps, do the errors above indicate misconfiguration? I don't want to install haskell-platform because it's too outdated. I need at least GHC >= 8. I'm on the latest stable release of Ubuntu if that makes a difference. -- Jun Inoue

5 11

Parsing a bunch of strings without backtracking
by Javran Cheng 16 Mar '17

16 Mar '17

Hi all, I come across an idea about parsing a bunch of strings, just want to share this idea and looking for some comments and maybe pointing me to some related articles. The idea is when you have: 1 <$ string "aabb" <|> 2 <$ string "aacc" you can rewrite it as: string "aa" >> (1 <$ string "bb" <|> 2 <$ string "cc") so that you don't have to deal with the common prefix "aa" twice. Then I further extend this idea: if we have a set of strings (s1, s2, ...), whose element is not a prefix of any other set member, why don't we turn things like (v1 <$ string s1 <|> v2 <$ string s2 <|> ...) into a "tree-structure" so we don't need to deal with any common prefix more than once? So this motivates my little toy implementation at https://gist.github.com/Javran/1cbfe9897d9a5c8fae5d20a33fd83813 basically given a list [(s1,v1),(s2,v2)...], we want to generate a parser equivalent to (v1 <$ string s1 <|> v2 <$ string s2 <|> ...) but perhaps with less backtracking. My code does this by turning the set of strings into a tree structure (see function "compact") and using this "Compact" representation as a driver to generate the parser. I used ReadP to have a concrete parser for testing, but this should work with any parsing library supporting MonadPlus. I think they are bunch of things that can be improved: - for now every intermediate node of "Compact" contains just a char, so this will end up generating a parser that has branch `char 'f' >> char 'o' >> 'o'` in it instead of the slightly more efficient version `string "foo"` - we could further attach a weight to each string, this allows rearranging (<|>) chains so that a more frequent string parser appears earlier. - if the input [(s1,v1),(s2,v2)...] are all known constants at compile time, probably TemplateHaskell can be used for generating the parser at compile time (as a Haskell expression). I'm not sure how difficult this would be though, as I have very limited understanding of TH. but before I explore further, I want to collect some comments as I said in the beginning. Best, -- Javran (Fang) Cheng

3 4

Re: [Haskell-cafe] Lazy vs Strict ByteStrings
by Dimitri DeFigueiredo 16 Mar '17

16 Mar '17

I think I need to be more specific here. My gripe with ByteString is that there are two distinct ByteString types disguised as one. There are “disguised” simply by having the same name. This leads me to think the use of ByteString will be simpler than it usually turns out to be. I fear Backpack may soon make this worse. Obviously, this is not exclusive to ByteString. Using the same name for strict and lazy versions is all over the place. Here is another example: https://hackage.haskell.org/package/unordered-containers/docs/Data-HashMap-… https://hackage.haskell.org/package/unordered-containers/docs/Data-HashMap-… But the problem is specially insidious with BytStrings because of their usage patterns and also because the process of finding out which version is which through GHC error messages is very inefficient. Here is a very ugly example where I believe I was misled by both ByteString types having the same name. I needed to make a “random looking but secretly not random” number and package it up in a 128-bit UUID. In other words, I wanted to mark the random numbers I create, but in a way that nobody else knows they are mine. The `hash` function from the cryptonite library accepts ByteString and its output can be converted to ByteString. The UUID type also has a function `fromByteString`. What could be easier? Here’s what I ended up with: import System.Random import Data.Maybe import Data.Word import Data.UUID import Crypto.Hash import Crypto.Hash.Algorithms import Data.ByteArray import Data.ByteString.Builder import qualified Data.ByteString as BS import Data.ByteString.Lazy as BSL -- Ugly! Step-by-step markAsSelf :: Word64 -> Word64 -> UUID markAsSelf selfDetectKey rand = let selfKeyAsLazyBS = toLazyByteString (word64BE selfDetectKey) randAsLazyBS = toLazyByteString (word64BE rand) hashInput = BSL.concat [randAsLazyBS, selfKeyAsLazyBS] digest = hash (toStrict hashInput) :: Digest SHA256 hashBitsStrict = BS.take 8 (convert digest) halfAndHalf = BSL.concat [randAsLazyBS, fromStrict hashBitsStrict] in fromJust (fromByteString halfAndHalf) secret :: Word64 secret = 12345 main = do r <- randomIO print (markAsSelf secret r) --------- end --------- in Data.ByteString.Builder toLazyByteString :: Builder -> ByteString -- exists toStrictByteString :: Builder -> ByteString -- was not found Similarly, in Data.UUID fromByteString :: ByteString -> Maybe UUID — only exists for lazy I think this lack of a common interface makes the code above a type conversion disaster and the process of debugging it painfully inefficient. Is there a better approach to go about doing this? Cheers, Dimitri -- 2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F

2 1

[ANN] Haskell Paris meetup on 2017-03-27
by lucas di cioccio 15 Mar '17

15 Mar '17

Dear cafe readers, The next Haskell Paris Meetup will take place on 2017-03-27 at Murex near Trocadéro in Paris. There will be two entry-level/intermediary-level talks (in French) as well as some time for socializing. You'll find more details about the event as well as a registration form at https://www.meetup.com/haskell-paris/events/238394643/ . Best, -- Lucas DiCioccio

1 0

Re: [Haskell-cafe] To [] Or Not To []
by Olaf Klinke 15 Mar '17

15 Mar '17

Well, Joachim, it certainly can not get easier than that. Thanks a lot! Olaf

1 0

Lazy vs Strict ByteStrings
by Dimitri DeFigueiredo 15 Mar '17

15 Mar '17

I just noticed that I avoid using ByteStrings because I tend to spend a huge amount of time reading GHC output and trying to figure out if I am/should be using the strict or the lazy version. I have to use both lazy/strict because different libraries use different versions. Maybe having different names would have helped. Am I doing something wrong or is the interface to ByteStrings a poor design? Cheers, Dimitri -- 2E45 D376 A744 C671 5100 A261 210B 8461 0FB0 CA1F

1 0