- Haskell-Cafe - Haskell.org

Run time module definition file location information?
by David Banas 25 Nov '15

25 Nov '15

Hi all, How can I get a running Haskell program to tell me where it’s looking, in order to satisfy “import …” statements? Thanks, -db

3 2

Comparison between fields of each record
by Jeon-Young Kang 24 Nov '15

24 Nov '15

Dear All. I'd like to compare fields of each record. here is my record. data Person = Person {name:: String, age:: Int } deriving(Show) data Relations = Friend | Older | Younger class Comparison a where compare:: a -> a -> Relations instance Comparison Person where compare Person a b Person a b | b1 == b2 = Friend | b1 > b2 = Older | b1 < b2 = Younger How can I fit it? Sincerely, Jeon-Young Kang

2 2

ANN: haskell-tor 0.1
by Adam Wick 24 Nov '15

24 Nov '15

Howdy - Galois is pleased to announce an initial release of haskell-tor. Haskell-tor is intended to be a full-featured, drop-in implementation of the Tor onion routing protocol. This release provides full support for resolving names and building connections via anonymized channels, as well as (less tested) support for running relay and exit nodes. There are still many tasks left to do, however, if you're interested in learning about and working on a Tor implementation, including support for hidden services, proper flow control, directory support, etc. So if you're interested, jump in! We welcome your patches. You can find haskell-tor on: GitHub: https://github.com/GaloisInc/haskell-tor Hackage: https://hackage.haskell.org/package/haskell-tor Haskell-tor is HaLVM-ready. - Adam

5 5

darcs 2.10.2 release
by Guillaume Hoffmann 23 Nov '15

23 Nov '15

The darcs team is pleased to announce the release of darcs 2.10.2 ! # Downloading # The easiest way to install darcs 2.10.2 from source is by first installing the Haskell Platform (http://www.haskell.org/platform) If you have installed the Haskell Platform or cabal-install, you can install this release by doing: $ cabal update $ cabal install darcs-2.10.2 Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.10.2.tar.gz and build it by hand as explained in the README file. The 2.10 branch is also available as a darcs repository from http://darcs.net/releases/branch-2.10 # What's new in 2.10.2 (since 2.10.1) # * optimize patch apply code memory use * make patch selection lazier in presence of matchers * switch patches retrieval order when using packs * switch from dataenc (deprecated) to sandi * finish updating help strings with new command names * clean contrib scripts * disable mmap on Windows * enhance darcs send message * fix quickcheck suite * shorter README with quickstart instructions * fixed the following bugs: * 2457: fix darcs-test command line options * 2463: building darcs on powerpc * 2444: added default interactivity parameter to isInteractive # Feedback # If you have an issue with darcs 2.10.2, you can report it on http://bugs.darcs.net/ . You can also report bugs by email to bugs(a)darcs.net, or come to #darcs on irc.freenode.net.

3 3

Munich Haskell Meeting, 2015-11-25 @ 19:30
by Christian Neukirchen 23 Nov '15

23 Nov '15

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, November 25 at Cafe Puck at 19h30. For details see here: http://chneukirchen.github.io/haskell-munich.de/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-nov-2015/ Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

Haskell job in Berlin
by Matthias Fischmann 23 Nov '15

23 Nov '15

Hei everybody, We are looking for people to join our Haskell team at liquid democracy e.V. in Berlin. Details: | https://liqd.net/job_haskell.html cheers, matthias

1 0

Running GHC LLVM output through LLVM bitcode linker first
by Clinton Mead 23 Nov '15

23 Nov '15

Is there a way to run the LLVM code (both generated by Haskell and provided by the user) though the LLVM bitcode linker to perform intermodule optimizations (like inlining) http://llvm.org/docs/CommandGuide/llvm-link.html Here's some example code: -- Main.hs -- {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE GHCForeignImportPrim #-} {-# LANGUAGE ForeignFunctionInterface #-} {-# LANGUAGE UnliftedFFITypes #-} {-# LANGUAGE BangPatterns #-} import GHC.Exts(Word(W#)) import GHC.Prim(Word#) foreign import ccall llvmid :: Word# -> Word# main = do line1 <- getLine let !(W# x1) = read line1 let !r1 = llvminc x1 print (W# r1) -- funcs.ll -- define fastcc i64 @llvminc(i64 inreg %x) { %r = add i64 %x, 1 ret i64 %r } When I compile like the following: ghc -O2 -fllvm -keep-s-files Main.hs funcs.ll I get an executable that performs correctly, but when I look at the assembly output in Main.s I get the following: callq suspendThread movq %rax, %rbp movq %rbx, %rdi callq llvminc movq %rax, %rbx movq %rbp, %rdi callq resumeThread This leads me to believe that this is being done like a c call through registers, but not inlined, though I'm not sure about this. I also suspect sending the "Main.ll" and "funcs.ll" files through the LLVM bitcode linker and then sending the resulting one bitcode to the LLVM compiler would perform these intramodule optimisations. Is there anyway to get GHC to use the LLVM bitcode linker to link all the LLVM files (both user provided and resulting from GHC compilation) though the LLVM bitcode linker first before the system linker?

2 1

[NL-FP 2016] 2nd CFP: Dutch Functional Programming Day 2016
by Atze Dijkstra 23 Nov '15

23 Nov '15

[My apologies for multiple received copies of the same message] 2nd Call for Participation: Dear all, The next Dutch Functional Programming day (NL-FP 2016) will be held on Friday, January 8, 2016 at the Utrecht University, The Netherlands. You are invited to participate and to give a presentation. At the end of the day we will have a joint dinner. On the web page http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome <http://foswiki.cs.uu.nl/foswiki/NlFpDay2016/WebHome> for the day you’ll find preliminary information which will be further filled in due time. Registration is by letting me know via email (with a subject header that begins with [NL-FP 2016]) whether you want to (1) participate, (2) join dinner, (3) give a presentation (please include title + abstract), also see the webpage for additional details. If you intend to participate, please let me know as soon as possible because we like to know how many people we can expect. Hope to meet you all in Utrecht at the next FP Day! Best regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze <http://www.cs.uu.nl/~atze> . /--| \ Fax : +31-30-2513971 .... | Email: atze(a)uu.nl <mailto:atze@uu.nl> ............... / |___\

1 0

Is there an overview of backend technologies for Haskell?
by Joachim Durchholz 23 Nov '15

23 Nov '15

Hi to all, I'm wondering how the various backend technologies are regarded. What trade-offs are involved (e.g. spineless-tagless vs. generating machine code, seems to be very, very different), what options there might be, what the choice would be if a compiler were to be written from scratch, that kind of stuff. The first two pages of a web search for "Haskell backends" returned only references to GHC's LLVM backend. Which was interesting but not an overview :-) URLs welcome. Regards, Jo

3 2

type operators and colon in GHC
by John Leo 22 Nov '15

22 Nov '15

According to sections 7.4.3 and 7.4.4 of the latest Haskell documentation https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-e… you can define (7.4.3) an infix type constructor as long as it begins with a colon, for example data a :*: b = Foo a b and furthermore (7.4.4) you can define an infix operator without having to use a colon if you enable the TypeOperators extension: data a * b = Foo a b However if I try the former without using TypeOperators I get this compiler error in 7.10.2: Illegal declaration of a type or class operator ‘:*:’ Use TypeOperators to declare operators in type and declarations Using TypeOperators fixes this, but then * without colon also works so I don't see the point of using colon anymore. My guess is this was some some kind of historical distinction which is no longer valid and the documentation needs to be updated. Is this true, or am I missing something? John

1 0

ANN: prefix-units 0.2.0
by Iustin Pop 22 Nov '15

22 Nov '15

Hi all, New version of my small library prefix-units (for parsing and formatting things like "10K"). Changes: * Incompatible API change to cleanup some initial design decisions: the two level `FormatOption`/`FormatMode` model is removed, the fixed unit of `FormatOption` is moved to a new constructor `FormatMode`, and `FormatOption` is removed entirely. This should be a simpler API, at the cost of breaking compatibility. * Fixed issue #3 (No support for negative numbers). * Worked around issue #1 (Add 'base' unit) by adding a mode that disables scaling; it should have the same effect without introducing an artificial unit. Feedback welcome, either via email or at https://github.com/iustin/prefix-units. happy hacking, iustin

1 0

Warning: Tab Character
by Jeon-Young Kang 21 Nov '15

21 Nov '15

Hello everyone. I am a newbie of Haskell, using Textmate on mac. I got the following warning. How can I fix it? Warning: Tab character Ok, modules loaded: Main. Sincerely, Young

2 2

NNOUNCE: Haskell Communities and Activities Report (29th ed., November 2015)
by Mihai Maruseac 21 Nov '15

21 Nov '15

On behalf of all the contributors, we are pleased to announce that the Haskell Communities and Activities Report (29th edition, November 2015) is now available, in PDF and HTML formats: http://haskell.org/communities/11-2015/report.pdf http://haskell.org/communities/11-2015/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. We hope you will find it as interesting a read as we did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editors collect all the contributions into a single report and feed that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ======================================== End of March 2015: target deadline for contributions to the May 2015 edition of the HCAR Report ======================================== Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editors for a simple e-mail reminder in March (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Mihai Maruseac <hcar at haskell.org> -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

1 0

RDF with Haskell
by Jeon-Young Kang 21 Nov '15

21 Nov '15

I am a newbie learning Haskell. I'd like to import RDF in Haskell as well as to do SPARQL. I went through RDF4H, Swish, and so on. But it is still difficult to understand them for me. Anyone can suggest me to learn that? or recommend any kinds of books or tutorials? Sincerely, Jeon-Young -- Department of Geography State University of New York at Buffalo jykang22(a)gmail.com Jeon-Young Kang

2 1

Re: [Haskell-cafe] AMP - how do you motivate this in teaching?
by Olaf Klinke 21 Nov '15

21 Nov '15

Albert's explanation is the best so far, IMHO. liftA2 is by far the most useful and reasonable function in Control.Applicative. Realizing that it can be made the definition of Applicative is what made me friends with that typeclass. As an algebraicist, to me Control.Monad.join is what distinguishes Monad from Applicative, although Albert's explanation is more accessible new programmers. I tend to explain monads by example of container monads mimicking powerset features, and join has a natural interpretation there. -- Olaf

1 0

ANN: cacophony 0.4.0, pipes-cacophony 0.1.2
by John Galt 20 Nov '15

20 Nov '15

cacophony[1] is a library which implements the Noise[2] protocol. Noise is a framework for cryptographic protocols based on ECDH key agreement authored by Trevor Perrin. pipes-cacophony[3] builds on cacophony to provide pipes that facilitate key agreement and secure messaging (in conjunction with, for example, pipes-network). -- John [1] http://hackage.haskell.org/package/cacophony [2] https://github.com/trevp/noise/blob/master/noise.md [3] http://hackage.haskell.org/package/pipes-cacophony

1 0

AMP - how do you motivate this in teaching?
by Johannes Waldmann 20 Nov '15

20 Nov '15

Because of AMP, I have to rewrite slides and example code for my lectures, and I don't like it. In fact I probably won't do it, and will advise students to return to ghc-7.8 - but then, how does that look? Really, my answer to [1] 3.5 Beginner friendliness How often did you say ... "A Monad is always an Applicative" is: never. (for "is a Functor" - often. In fact, always) Now, I don't want to bring on another general discussion of AMP - instead I'd like to hear from people who use monads in teaching (e.g., to define semantic domains) about how they sell "Applicative m =>" to their students. (The intersection of AMPers and teachers is non-empty?) - Johannes [1] https://wiki.haskell.org/Functor-Applicative-Monad_Proposal

12 13

Re: [Haskell-cafe] [Coq-Club] ANN: linearscan, linearscan-hoopl 1.0.0
by John Wiegley 20 Nov '15

20 Nov '15

>>>>> Beta Ziliani <bziliani(a)famaf.unc.edu.ar> writes: > I'd be interested to know what was the outcome of the project from the point > of view of BEA Systems. Is there any report about it? >From BAE's point of view, we gained some industrial perspective. Separately, I have prepared an experience report that is currently seeking a venue. John

1 0

ANN: stack-0.1.8.0
by Emanuel Borsboom 20 Nov '15

20 Nov '15

New version released of Stack, a build tool. See README <https://github.com/commercialhaskell/stack/tree/release#how-to-install> for installation and upgrade instructions. There are now Windows installers available: download them here <https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upg…>. In addition, new Fedora 23 packages are available here <https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upg…> . Note that, starting with v0.1.8.0, releases of Stack will always have an even-numbered second-to-last version component. Odd second-to-last version components are reserved for unstable builds. Major changes: - GHCJS can now be used with stackage snapshots via the new compiler field. - Docker integration works with non-FP Complete generated images #531 <https://github.com/commercialhaskell/stack/issues/531> Other enhancements: - Added an allow-newer config option #922 <https://github.com/commercialhaskell/stack/issues/922> #770 <https://github.com/commercialhaskell/stack/issues/770> - When a Hackage revision invalidates a build plan in a snapshot, trust the snapshot #770 <https://github.com/commercialhaskell/stack/issues/770> - Added a stack config set resolver RESOLVER command. Part of work on #115 <https://github.com/commercialhaskell/stack/issues/115> - stack setup can now install GHCJS on windows. See #1145 <https://github.com/commercialhaskell/stack/issues/1145> and #749 <https://github.com/commercialhaskell/stack/issues/749> - stack hpc report command added, which generates reports for HPC tix files - stack ghci now accepts all the flags accepted by stack build. See #1186 <https://github.com/commercialhaskell/stack/issues/1186> - stack ghci builds the project before launching GHCi. If the build fails, optimistically launch GHCi anyway. Use stack ghci --no-build option to disable #1065 <https://github.com/commercialhaskell/stack/issues/1065> - stack ghci now detects and warns about various circumstances where it is liable to fail. See #1270 <https://github.com/commercialhaskell/stack/issues/1270> - Added require-docker-version configuration option - Packages will now usually be built along with their tests and benchmarks. See #1166 <https://github.com/commercialhaskell/stack/issues/1166> - Relative local-bin-path paths will be relative to the project’s root directory, not the current working directory. #1340 <https://github.com/commercialhaskell/stack/issues/1340> - stack clean now takes an optional [PACKAGE] argument for use in multi-package projects. See #583 <https://github.com/commercialhaskell/stack/issues/583> - Ignore cabal_macros.h as a dependency #1195 <https://github.com/commercialhaskell/stack/issues/1195> - Pad timestamps and show local time in —verbose output #1226 <https://github.com/commercialhaskell/stack/issues/1226> - GHCi: Import all modules after loading them #995 <https://github.com/commercialhaskell/stack/issues/995> - Add subcommand aliases: repl for ghci, and runhaskell for runghc #1241 <https://github.com/commercialhaskell/stack/issues/1241> - Add typo recommendations for unknown package identifiers #158 <https://github.com/commercialhaskell/stack/issues/158> - Add stack path --local-hpc-root option - Overhaul dependencies’ haddocks copying #1231 <https://github.com/commercialhaskell/stack/issues/1231> - Support for extra-package-dbs in ‘stack ghci’ #1229 <https://github.com/commercialhaskell/stack/pull/1229> - stack new disallows package names with “words” consisting solely of numbers #1336 <https://github.com/commercialhaskell/stack/issues/1336> - stack build --fast turns off optimizations Bug fixes: - Fix: Haddocks not copied for dependencies #1105 <https://github.com/commercialhaskell/stack/issues/1105> - Fix: Global options did not work consistently after subcommand #519 <https://github.com/commercialhaskell/stack/issues/519> - Fix: ‘stack ghci’ doesn’t notice that a module got deleted #1180 <https://github.com/commercialhaskell/stack/issues/1180> - Rebuild when cabal file is changed - Fix: Paths in GHC warnings not canonicalized, nor those for packages in subdirectories or outside the project root #1259 <https://github.com/commercialhaskell/stack/issues/1259> - Fix: unlisted files in tests and benchmarks trigger extraneous second build #838 <https://github.com/commercialhaskell/stack/issues/838>

2 1

On Hiatus Until January 2016: Haskell Weekly News
by Kim-Ee Yeoh 20 Nov '15

20 Nov '15

Regrettably, I must announce that Haskell Weekly News will go on hiatus until the new year. I recognize that the last issue was back in September. It's been said that "The more a man possesses over and above what he uses, the more careworn he becomes." In my case, mundane possessions have indeed insisted on being attended to. I wish every reader a fine holiday season. -- Kim-Ee Editor of Haskell Weekly News

1 0

ANN: linearscan, linearscan-hoopl 1.0.0
by John Wiegley 20 Nov '15

20 Nov '15

linearscan[1] is a linear scan register allocator[2], written in Coq[3], and extracted to Haskell, as a library for Haskell programs that need to allocate registers. It may also be used directly from Coq. This project is the result of a year-long effort, funded by BAE Systems[4], to explore the application of dependent-types and mathematical verification to a typical engineering task. During the course of construction, several hundred theorems about the code were proven -- although exhaustive coverage was not, in the end, achievable given our time constraints. To remedy this, and as a test of the extraction to Haskell, an optional runtime verifier was built to certify the resulting allocations. Coq 8.5b2[5] was used, as well as the ssreflect[6] library created for that version[7]. linearscan further relies on another library, coq-haskell[8], that I created to facilitate inter-operation between Haskell and Coq. For those using Hoopl[9] to represent program graphs, incorporating linearscan is quite easy: provide an instance of NodeAlloc using the linearscan-hoopl[10] library. Examples of doing so are provided in the test suite for that library. The allocation algorithm implemented by this library was first written in Java by Hanspeter Mössenböck and Michael Pfeiffer[11], and later improved upon by Christian Wimmer[12], whose master's thesis provided the specification for our implementation. John Wiegley BAE Systems Footnotes: [1] http://hackage.haskell.org/package/linearscan [2] http://www.cs.ucla.edu/~palsberg/course/cs132/linearscan.pdf [3] https://coq.inria.fr/ [4] http://www.baesystems.com/en-us/our-company/inc-businesses/electronic-syste… [5] https://coq.inria.fr/news/125.html [6] http://ssr.msr-inria.inria.fr/ [7] http://ssr.msr-inria.inria.fr/FTP/ [8] https://github.com/jwiegley/coq-haskell [9] https://hackage.haskell.org/package/hoopl [10] http://hackage.haskell.org/package/linearscan-hoopl [11] http://dl.acm.org/citation.cfm?id=647478.727924 [12] http://www.christianwimmer.at/Publications/Wimmer04a/

1 0

Why is my mappend so slow?
by martin 20 Nov '15

20 Nov '15

Hello all, I wrote a Logger which, under certain conditions, prepends log-entries to a log and a Monoid instance of it. But as soon as I mappend two Loggers my performance drops by 50%. This even happens when I mappend mempty as shown below in --<2--. I understand that the system has to do *something*, but it seems to cost a bit much. Without the strictness annotation in --<1-- the performance degradation is even more dramatic (orders of magnitude). The profile tells me that more that 50% of the time is spent in mappend. COST CENTRE MODULE %time %alloc mappend.\ Logger 50.6 35.8 logCount'.f Logger 18.7 40.3 logCount' Logger 5.4 0.0 Why is that so, and can I do anything about it? I am willing to change the overall design if required. This is the code -- | A writer does the formatting newtype Wtr a log = Wtr {runWtr :: a -> log} -- | A looger is a writer plus an internal state data Logger a log = Lgr {runLogger :: a -> log -> (log, Logger a log)} instance Monoid (Logger a log) where mempty = Lgr (\_ l -> (l,mempty)) mappend lgr1 lgr2 = Lgr $ \a l -> let !(log1',!lgr1') = runLogger lgr1 a l --<1-- !(log2',!lgr2') = runLogger lgr2 a log1' --<1-- in (log2', mappend lgr1' lgr2') and this is how I test it -- | Count calls __s__ and write log when s has reached nxt and then every dn calls logCount' :: Monoid log => Int -> Int -> Int -> Wtr (Int,a) log -> Logger a log logCount' dn nxt s wtr = Lgr f where f a l = if s == nxt then (runWtr wtr (s,a) <> l, logCount' dn (nxt+dn) (s+1) wtr) else (l, logCount' dn nxt (s+1) wtr) -- | Count calls and write log every dn calls logCount dn = logCount' dn dn 0 -- testLogger :: Logger Int Int [String] -> [String] testLogger lgr xs = fst $ foldl' f ([],lgr) xs where f (log', lgr') x = runLogger lgr' x log' ex_wtr :: Wtr (Int,a) [String] ex_wtr = Wtr $ \(x,_) -> ["Counted to " ++ (show x)] ex_wtr2 :: Wtr Int [String] ex_wtr2 = Wtr $ \x -> ["Counted to " ++ (show x)] ex_inputs :: [Int] ex_inputs = [1..10000000] ex_logger = mempty <> logCount 300000 ex_wtr <> mempty --<2-- -- ex_logger = logCount 300000 ex_wtr ex_main = do timeIt $ putStrLn $ ppShow $ testLogger ex_logger ex_inputs main = ex_main

4 8

Partition int 180. Out of memory
by Kees Bleijenberg 19 Nov '15

19 Nov '15

I want to partition the integer n=180 with terms >=5 I.e. n=15 => [[5,5,5],[8,7],[9,6],[10,5],[15]] The function part does this. memopart does it with memoization a lot faster. mempart works fine on my machine until n=120. For n=130 I get 'out of memory'. For other reasons I work on Win64 with ghc32. To save memory I replaced Int with Word8. I also replaced [Word8] with B.ByteString (memopartB). But no luck. I still get 'out of memory' for n=130. I run the program with: part +RTS -M4294967295 (429... is according to ghc the max memory I can use) Any ideas how to solve this? What is the most memory efficient replacement for a list? module Main ( main,part,memopart ) where import Data.Int import System.Time import qualified Data.ByteString.Lazy as B import Data.Word import Data.List (intercalate) part :: Int -> [[Int]] part 0 = [[]] part n = [x:y | x <- [5..n], y <- part (n-x), [x] >= take 1 y] partB :: Word8 -> [B.ByteString] partB 0 = [B.empty] partB n = [B.cons x y | x <- [5..n], y <- partB (n-x), B.singleton x >= y] memopart a = memo !! a where memo = [[]] : [[x:y | x <- [5..n], y <- memo !! (n-x), [x] >= take 1 y] | n <- [5..]] memopartB :: Int -> [B.ByteString] memopartB a = memo !! a where memo :: [[B.ByteString]] memo = [B.empty] : [[B.cons x y | x <- [5 :: Word8 .. n :: Word8], y <- memo !! minusWord8 n x, B.singleton x >= y] | n <- [5 :: Word8 ..]] minusWord8 :: Word8 -> Word8 -> Int minusWord8 c d = (fromIntegral c :: Int) - (fromIntegral d:: Int) main = do startTime <- getClockTime -- print $ length $ memopart 50 putStrLn $ showPartBRes $ memopartB 120 stopTime <- getClockTime putStrLn ("Time: " ++ timeDiffToString (diffClockTimes stopTime startTime)) showPartBRes :: [B.ByteString] -> String showPartBRes res = intercalate ", " $ map showB res where showB :: B.ByteString -> String showB arr = '[' : intercalate "," (B.foldr (\w acc -> show w : acc) [] arr) ++ "]"

3 3

ANN: haskell-src-exts 1.17
by Matthew Pickering 18 Nov '15

18 Nov '15

Dear list, I am pleased to report that Peter has just released a new version of haskell-src-exts. I include the release notes below. This release fixes a large number of long standing bugs so I urge all users to update their projects to use this new version. If haskell-src-exts fails to parse a program which GHC accepts then please report an issue to the issue tracker. Best wishes, Matt --------- I am pleased to announce the release of haskell-src-exts-1.17.0! Hackage: https://hackage.haskell.org/package/haskell-src-exts-1.17.0 GitHub: https://github.com/haskell-suite/haskell-src-exts This release brings bugfixes, as well as the following language features: * Type wildcards and expression holes (#252). * Pattern Synonyms (#197). The full changelog is available at https://github.com/haskell-suite/haskell-src-exts/blob/1.17.0/CHANGELOG This release is brought to you by: Matthew Pickering Michael Walker Simon Marlow Neil Mitchell JP Moresmau Артур Файзрахманов phischu Michael Sloan m00nlight Niklas Broberg Stijn van Drongelen Jakub Kozlowski Leonid Onokhov Matthew Pickering is a force of nature who deserves a special mention for all his contributions to this release. Peter

1 0

Call For Presentations: Compose 2016, New York, Feb 4-5
by Gershom B 18 Nov '15

18 Nov '15

Compose is a conference for typed functional programmers, focused specifically on Haskell, OCaml, F#, and related technologies. It will be held in New York on Thursday and Friday, Feb 4-5, 2016. Registration will be open shortly. http://www.composeconference.org/ To get a sense of Compose, you can check out the great talks from the 2015 conference: http://www.composeconference.org/2015/summary/ Below is our call for presentations. We recognize the deadline is tight, so feel free to submit proposals and ideas on the less-polished side. http://www.composeconference.org/2016/cfp/ * * * The audience for Compose is Haskell, OCaml, F#, or SML developers who are looking to increase their skills or learn new technologies and libraries. Presentations should be aimed at teaching or introducing new ideas or tools. We are also interested in presentations aiming at taking complex concepts, such as program derivation, and putting them into productive use. However proposals on anything that you suspect our audience may find interesting are welcome. The following are some of the types of talks we would welcome: Library/Tool Talks — Exploring the uses of a powerful toolkit or library, be it for parsing, testing, data access and analysis, or anything else. Production Systems — Experience reports on deploying functional techniques in real systems; insights revealed, mistakes made, lessons learned. Theory made Practical — Just because it’s locked away in papers doesn’t mean it’s hard! Accessible lectures on classic results and why they matter to us today. Such talks can include simply introducing the principles of a field of research so as to help the audience read up on it in the future; from abstract machines to program derivation to branch-and-bound algorithms, the sky’s the limit. We also welcome proposals for more formal tutorials. Tutorials should be aimed at a smaller audience of beginner-to-novice understanding, and ideally include hands-on exercises. The due date for submissions is December 14, 2015. We will send out notice of acceptance by December 24th. We prefer that submissions be via the EasyChair website (https://easychair.org/conferences/?conf=compose2016) Please suggest a title, and describe the topic you intend to speak on. Talks can be either 30 or 45 minutes, please indicate how much time you would prefer to take. Additional information may be included on both your expertise and the interesting elements of your topic, going on what might be included in a public abstract. Furthermore, if your abstract doesn't feel "final"—don't worry! We'll work with you to polish it up. If you want to discuss your proposal(s) before submitting, or to further nail down what you intend to speak on, please feel free to contact us at info(a)composeconference.org. We're happy to work with you, even if you are a new or inexperienced speaker, to help your talk be great. * * * Diversity We would like to put an emphasis on soliciting a diverse set of speakers - anything you can do to distribute information about this CFP and encourage submissions from under-represented groups would be greatly appreciated. We welcome your contributions and encourage you to apply! Best, Gershom

1 0

reactive-banana project examples
by Michael Litchard 17 Nov '15

17 Nov '15

Could I get some pointers to projects using reactive-banana. I'm looking for projects that have code testing their Behaviors.

1 0

Re: [Haskell-cafe] turn off "thread blocked indefinitely in an STM transaction"?
by Johannes Waldmann 17 Nov '15

17 Nov '15

myThreadId >>= newStablePtr ; atomically retry Yes, that works. Thanks.

1 0

Re: [Haskell-cafe] turn off "thread blocked indefinitely in an STM transaction"?
by Johannes Waldmann 17 Nov '15

17 Nov '15

Ah, neat. I get the idea. But does it work here? import Control.Concurrent.STM import Foreign.StablePtr main = atomically retry >>= newStablePtr ghc -threaded -rtsopts -O2 sp.hs ./sp +RTS -N sp: thread blocked indefinitely in an STM transaction - J.

2 1

turn off "thread blocked indefinitely in an STM transaction"?
by Johannes Waldmann 17 Nov '15

17 Nov '15

I find the following mildly annoying: Prelude> import Control.Concurrent.STM Prelude Control.Concurrent.STM> atomically retry *** Exception: thread blocked indefinitely in an STM transaction Is there a way to not raise this exception, and block the thread? I don't see this behaviour (raising the exception) mentioned in the API docs nor in the defining paper (Composable memory transactions, PPoPP'05) that is referenced there. I understand it might come in handy for debugging, but sometimes (e.g., for teaching) I might really want a transaction that never commits. For instance, I am forkIO'ing some worker threads and the main program really should do absolutely nothing. So I thought I could just block the main thread. I can make some work-around with forM [1..n] $ \ p -> ( if p < n then void . forkIO else id ) $ forever $ do but that feels clumsy (since asymmetric). - J.W.

2 1

the last mile in haskell performance
by Alberto G. Corona 17 Nov '15

17 Nov '15

Looking at this: https://downloads.haskell.org/~ghc/6.12.3/docs/html/users_guide/primitives.… It seems that it is impossible to manage data in Haskell within a core without L1 cache faults. Except for unboxed arrays of primitive types. Since it is impossible to have unboxed arrays of user-defined types. Am I right? This is definitively very bad for tasks that are inherently single threaded and in general for the image of Haskell as a practical language. I have more to say about that, but I would like to know first if I´m right and second If there is some idea to going on to permit user defined boxed datatypes. Or if there is some low level trick for having it using foreign call and unsafeCoerce in some way, I know that the language ATS has unboxing a la carte.... -- Alberto.

9 14

Streaming a Conduit into a lazy list
by Jules Bean 17 Nov '15

17 Nov '15

Conduits seem like a popular and useful way to compose operations which consume and produce streams at various speeds. I hadn't used them before, so apologies for any obvious mistakes below. Conduits have lots of power in terms of how you can interleave monadic effects with the streaming; but I found that I had a stream with no effects at all and I wanted to convert it back into haskells more simplistic representation, lazy lists. This is probably a well-known trick, but I couldn't find how to do this from googling, so here is the solution I found in case it helps someone else: > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts #-} > module Main where > > import Data.Conduit > import Control.Monad.Catch > import Control.Monad.Trans.Resource > import Control.Monad.Writer > import Control.Monad.Identity > import qualified Data.Conduit.List as CL > import Data.Typeable > > source123Error :: Monad m => Source m Int > source123Error = do > yield 1 > yield 2 > yield 3 > error "error" A source which produces some data and then hangs, to test lazy production. One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens: *Main> :t runIdentity (source123Error $$ CL.consume) runIdentity (source123Error $$ CL.consume) :: [Int] *Main> runIdentity (source123Error $$ CL.consume) *** Exception: error But what we can do instead is push the data out via the Writer monad: > tellEverything :: MonadWriter [a] m => Sink a m () > tellEverything = awaitForever (\x -> tell [x]) *Main> :t source123Error $$ tellEverything source123Error $$ tellEverything :: MonadWriter [Int] m => m () *Main> snd $ runWriter (source123Error $$ tellEverything) [1,2,3*** Exception: error Success! A lazily produced list. If your output is of any size - and depending on the compositions pattern in your code - it may be much faster to use this version: > tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m () > tellEveryEndo = awaitForever (\x -> tell (Endo (x:))) *Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne) [1,2,3*** Exception: error I found a further case where the Conduit I was trying to run was pure but had a 'MonadThrow' constraint. You can use the same approach here, using the ExceptionT transformer to satisfy the MonadThrow constraint. > data MyError = MyError deriving (Show,Typeable) > instance Exception MyError > > source123Throw :: MonadThrow m => Source m Int > source123Throw = do > yield 1 > yield 2 > yield 3 > throwM MyError *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Error $$ tellEverything) [1,2,3*** Exception: error *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything) [1,2,3] An aside: I tried to measure the speed difference between the list-mappend and Endo-mappend approaches with the following code. count2N uses a binary-tree shaped recursion so it should be fairly bad for list-mappend with lots of long lists on the left. > count2N :: Monad m => Int -> Source m Int > count2N 0 = yield 0 > count2N n = count2N (n-1) >> count2N (n-1) > speedTest1 = print . length . snd . runWriter $ (count2N 24 $$ tellEverything) > speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $ (count2N 24 $$ tellEveryEndo) With -O or -O2 I measure no speed difference between these, they both take a bit over 2 seconds. With no optimisation flag, speedTest2 is slower, 17 seconds vs 11 seconds. I'm quite surprised the Endo version isn't faster, it seems like something is rewriting those list appends? Cheers, Jules

2 7

Darcs vs Git
by Geraldus 17 Nov '15

17 Nov '15

Hi friends! I love Haskell very much. So, I'm very interested in using Darcs. Is there some documentation explaining diffrences between Darcs and Git. Is there something that makes Darcs more robust rathen that Git. Does Darcs have some Emacs support (something like `magit`)? And one other question. Currently, I have no collaborators and use Git majorly myself to have version control, e.g. to revert some bad code, to have a nice log with code diffs and comments, and etc. But in future I will need something like GitHub for collaboration, is there a good solution for Darcs' hub already?

10 28

model checking for (subset of) concurrent Haskell?
by Johannes Waldmann 17 Nov '15

17 Nov '15

For model checking concurrent and distributed imperative programs, there's the Promela language, and the Spin model checker ( http://spinroot.com ) than can explore/enumerate a finite state space of a system and decide validity of LTL formulae. Is there something similar for Haskell models of concurrency? Ideally, some subset of Haskell (containing enough of Control.Concurrent.*) as an alternative for Promela. It should even be possible to put the model checking in an alternative implementation of respective monad (STM, IO for MVars) so the whole thing is an embedded DSL. somewhat related: this project is about a verified model checker: https://cava.in.tum.de/ (ML code generated from Isabelle) but my interest is in model-checking concurrent programs in functional notation. - J.W.

3 2

New Functional Programming Job Opportunities
by Functional Jobs 16 Nov '15

16 Nov '15

Here are some functional programming job opportunities that were posted recently: Haskell Developer (ON SITE) at CJ Affiliate by Conversant https://functionaljobs.com/jobs/8867-haskell-developer-on-site-at-cj-affili… Software Engineer - Functional Programmer - Erlang at Change Healthcare https://functionaljobs.com/jobs/8866-software-engineer-functional-programme… Cheers, Sean Murphy FunctionalJobs.com

1 0

Re: [Haskell-cafe] haskell-src-exts maintenance
by malcolm.wallace 16 Nov '15

16 Nov '15

We too have been waiting a long time for a refreshed release of HSE. If Matthew has already made the edits, and we are simply awaiting the package's release to Hackage, perhaps Matthew should go ahead make that release himself, and petition the Hackage admins to accept it, in view of the official maintainers' long silence? Regards, Malcolm On 12 Nov, 2015,at 05:37 PM, Matthew Pickering <matthewtpickering(a)gmail.com> wrote: Peter, Please can you do the release. I completed the work updating HSE several months ago, a much better version of HSE has been waiting on the master branch since then. I thank you for providing helpful review for the patches I submitted but since then I have sent three emails asking about the release. After the second you promised to do a release at the end of October but that never happened. It is a shame that the user's of HSE have had to live with many long standing bugs when they have been fixed for months. If you can not do it for whatever reason then please can you add me as a maintainer on hackage and the github repo so that users can get an updated version of HSE. Best wishes, Matt On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson <jonsson.peter.a(a)gmail.com> wrote: I’m not even going to bother to CC haskell-cafe since that will just bounce or go into a black hole. I exchanged a couple of mails with David (Lemmih) and my impression was that he was going to act upon some things but I didn’t follow up on that so there was probably some miscommunication between the two of us. I’ve merged some things and reviewed some patches. I agree with Neil that stable things should be merged and the yearly release of HSE should be made. I don’t want to rush things out through the door at any cost though—I believe HSE’s users are better served by something that is a strict improvement and contains more features than the last release compared to something that has even more features but is a bit shaky and requires a new major version of HSE in just a month or two which would force the client code to be re-tested and re-released. Best Wishes, Peter On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell(a)gmail.com> wrote: As a very heavy HSE user (HLint and Hoogle), who has had a reasonably close working relationship with all of Niklas (my SoC mentor and my SoC mentee), Roman and Peter (a fellow supercompiler developer) and Matt (currently hacking on HLint), I thought I should weigh in. The current state of HSE is a little forlorn - there are 22 open pull requests, everything from reducing algorithm complexity (an accidental n^3), fixing the default encoding (should be UTF8) and lots of actual parser fixes. A lot of this is good stuff, and the high level of external contributions is a really good sign. But they need to be merged and reviewed, and it seems the bandwidth just isn't there at the moment. Given Matt's comments on the existing tickets, and the triage he's already performing on the repo, I have high hopes that Matt could provide a bit more of the time and attention. Peter, perhaps a co-maintainer would be good for a little while? If it's not soon then please could you add myself and Christian to the maintainers so that we can perform some short term maintenance. My immediate plan of action would be 1. Immediately cut a 1.17 release from the master branch as it contains much better parsing of lifted constructors which are becoming more prevalent. 2. Review and merge recent pull requests. 3. Update the parser as far as possible with missing features. 4. Release 1.18 with these improvements within 1 month. Awesome! Although as a preference I'd go for as much of 2 as you can in a couple of days before doing 1 - a lot of the patches are simple and valuable, and a 2 day wait isn't going to be too problematic. Thanks, Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

2 1

The last decade: what has changed, was has stayed the same?
by Joachim Durchholz 16 Nov '15

16 Nov '15

Hi all, I used to be interested in Haskell roughly a decade ago, then life happened. Now that I'm setting up project work, I'm interested in what has been happening in the meantime. I read a bit on the usual pages, did a quick scan of the mailing list, didn't find out what the important questions of today are and what answers exist. Some ideas of relevant questions below. Feel free to pose and answer your own questions :-) After learning the bare language, how long does it take a competent programmer to become confident in the performance of his Haskell code? After learning the bare language, how long does it take a competent programmer to know when and when not to use strictness annotations/operators? I'm seeing a lot of typesystem golf happening. Is this teachable to the average competent programmer? Is it relevant to everyday programming such as business logic, database access, or webpage generation? (If no, for what programming endeavours is it relevant?) What's the status of debugging - I dimly remember a rough consensus that stack traces are hard to interpret in a meaningful way. (I know that debugging is far less important for a referentially transparent language than for others, but it would still be interesting.) What's the status of all the "boring stuff": - logging - profiling - dialog layout - input validation - database interaction - webpage generation, webflow - multi-tiered applications On the "instant to-do" side: What would a competent programmer need to do to become a competent Haskell programmer? (I suspect the usual set of toy projects will not work. Toy projects give you only so much mileage; in particular, you don't learn anything about what patterns will hold up for larger projects and what patterns won't scale.) Regards, Jo

2 2

Type-level lazy bool operations
by Dmitry Olshansky 16 Nov '15

16 Nov '15

Hello, cafe! There are some type-level boolean operation (If, &&, ||, Not) in Data.Type.Bool. Are they lazy enough? I faced with problem and it seems that the reason is non-lazy "If". I.e. both (on-True and on-False) types are trying to be calculated. Does it work in this way really? Could it be changed? Then, looking into source I see such definition for (&&) -- | Type-level "and" type family a && b where 'False && a = 'False 'True && a = a a && 'False = 'False a && 'True = a a && a = a Why we need the last three rules? Does it mean that an order of type calculation is totaly undefined? Dmitry

2 1

wxHaskell can now be run multiple times in GHCi
by Henk-Jan van Tuyl 15 Nov '15

15 Nov '15

L.S., Good news for people who want to develop wxHaskell programs by experimenting in GHCi: wxHaskell programs can now be run multiple times in GHCi (GHC 7.10.2, 32 bit). Running a wxHaskell program in the 64 bit version of the interpreter results in the message: addDLL: could not load DLL This is caused by a GHC bug and is reported in GHC bug ticket 3242 [0], it should be solved in GHC 8.0.1 (The 32 bit GHCi crashes when exited, after running a wxHaskell program, but this is not a problem for application developers.) Regards, Henk-Jan van Tuyl [0] https://ghc.haskell.org/trac/ghc/ticket/3242 -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

1 0

Mono-whatever
by David Feuer 15 Nov '15

15 Nov '15

Does any package define a type like this? data X :: * -> k -> k -> * where X :: b -> X b t t So instance (MonoFoldable b, Element b ~ t) => Foldable (X b t) where foldMap f (X b) = ofoldMap f b

1 0

Daunting heap profile when using (<>)
by martin 14 Nov '15

14 Nov '15

Hello all, I have a Logger which produces log entries and a new version of itself newtype Logger evt dom log = Lgr {runLogger :: Timed evt -> dom -> (log, Logger evt dom log)} Loggers are used in a function like this runSim :: (Ord evt, Monoid log) => SimBehaviour evt dom log -> SimState evt dom log -> SimState evt dom log runSim (!lgr, !hdr, xtp) (!log,!dom,!evq) = case step of Nothing -> (log, dom, evq) -- end of simulation Just (newEvq, newDom, newHdr, newLgr, newLog) -> runSim (newLgr,newHdr,xtp) (newLog,newDom,newEvq) where -- check for end conditions or run handler step = do (evt, evts) <- H.view evq -- no more Events -> Nothing if xtp (evt,dom) then Nothing else let (evq', dom', hdr') = runHandler hdr evt dom (log',lgr') = runLogger lgr evt dom' -- <-- -- append new event and new log entries in return (evq'<>evts, dom', hdr', lgr', log'<>log) -- <-- I then wrote a function to combine two Loggers addLgr (lgr1) (lgr2) = Lgr lgr where lgr tev dom = let (log1', lgr1') = runLogger lgr1 tev dom (log2', lgr2') = runLogger lgr2 tev dom (!log') = log2' <> log1' -- x -- -- in (log2', addLgr lgr1' lgr2') in (log', addLgr lgr1' lgr2') When called a million times, this produces a heap profile which climbs steadily (with or without the stricness annotation in line x). When I omit the (<>) as in the commented line, the heap stays flat. My log is really just a list of strings and most of the time the loggers do not produce any output, i.e. they return an empty list. Am I on the right track, that this trouble is probably caused by laziness and that forcing strictness is the way to go? Could it be that this is because ! does not fully evaluate its argument, but just to WHNF? Or is there a more obvious reason, I just fail to see. Where to go from here?

2 5

test coverage of Parsec parsers
by Aaron VonderHaar 14 Nov '15

14 Nov '15

Hi, I'm adding HUnit tests to a parser that uses Parsec, and I wanted to see test coverage of my parser. I've successfully used hpc to get a coverage report, but it has a significant deficiency: An expression in my parser will show as covered if the expression is ever evaluated, but I'd really like to see branch coverage of the parser monads. For example, if I have a single test that parses the string "*" with the following parser: plusOrStar = do result <- (string "+" <|> string "*") _ <- (many $ string " ") return result then hpc will report that all the code is covered, but I'd like to be able to see the fact that (string "+") only ever failed, and that (string "*") only ever succeeded. Are there any existing tools for getting that sort of coverage report for parsers or monads? Is there an approach other than hpc that I should be considering to get confidence in my test suite? If not, I understand that hpc works by doing source-code transformation--does it seem like a reasonable endeavor to try to customize it to do what I am interested in? Thanks, --Aaron V.

1 0

Do I Need To Write An Instance for Assertable Here?
by Michael Litchard 13 Nov '15

13 Nov '15

Below is some test code I am writing for my game, the link to the entire codebase, the error message and some discussion main :: IO () main = defaultMain [ testGroup "EventNetwork Input" [testBuffer "bBuffer" Populated] ] testBuffer :: String -> BufferState -> Test testBuffer name Populated = testCase name $ assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100")))) testBuffer name Empty = testCase name $ assert $ bufferEmptied (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (Data.Text.pack "100")))) bufferPopulated :: UAC -> MomentIO Bool bufferPopulated ev = do let eInput = ev <$ never eValidated = toVAC <$> eInput bBufferMap <- (buffer eValidated eClear) :: MomentIO (Behavior BufferMap) let r2 = [(Just $ BufferMap $ M.insert (AID (Data.Text.pack "100")) (toVAC ev) (M.empty :: M.Map AID VAC))] r1 <- liftIO $ ((interpret (eBuffer bBufferMap) []) :: IO [Maybe BufferMap]) return $ r1 == r2 bufferEmptied :: UAC -> MomentIO Bool bufferEmptied ev = undefined eBuffer :: Behavior BufferMap -> Event a -> Event BufferMap eBuffer bBufferMap nvr = bBufferMap <@ (() <$ nvr) eClear = Clear <$ (() <$ never) When I run stack build I get tests/Spec.hs:26:19: No instance for (Test.HUnit.Base.Assertable (MomentIO Bool)) arising from a use of ‘assert’ In the expression: assert In the second argument of ‘($)’, namely ‘assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100"))))’ In the expression: testCase name $ assert $ bufferPopulated (UAC (PlayerCommand (Move (ToPlanetName Mongo)) (AID (pack "100")))) The problem lies with buffer. It relies on accumB which requires the MomentIO monad. I considered writing an instance for Assertable, but I think that's a red-herring and the answer lies elsewhere. I need to reconcile the fact that assert wants an IO Bool, but accumB wants a MomentIO. Maybe I do need to write an instance for Assertable. Here's the link to the project:https://github.com/mlitchard/emporos/tree/banana-1.0.0/src

2 2

Where did these threads come from?
by David Turner 13 Nov '15

13 Nov '15

Hi all, I'm working on a server process that has (by design) fairly high memory usage but serves relatively few requests and spends most of its time idle. By 'fairly high' I mean 100s of MB, nothing ridiculous. I'm trying to improve its quiescent CPU usage as this is currently the limiting factor for how cheaply we can run this service - we're aiming for the cheapest t-class EC2 machine we can get. The quiescent CPU usage is currently about 50%. This seems to be largely due to the idle GC, because running with -I0 cuts it down to about 0.3%. Pretty much every time any thread wakes up it triggers the idle GC a short while later and because of the high memory usage these GCs are somewhat expensive. Using threadscope I found the biggest problem was the reaper thread in resource-pool which wakes up every second whether there's anything to reap or not. Fortunately this was easy to spot as the reaper thread labels itself as such. I've replaced this with an event-driven reaper that only wakes up on demand and cut the baseline from 50% down to just under 10%. There are two more threads I can now see waking up periodically in threadscope, with respective periods approximately 10 sec and 30 sec. I have a hunch what the 30-sec one is but no idea about the 10-sec one. If I can kill off the 10 sec one then that should take CPU usage down to <5% which would be just fine. My question: is there any reliable way to determine where these threads came from, in terms of the location of the forkIO call that made them? I've just been looking for likely candidates and labelling threads and this is rather tedious. Cheers, David

2 2

Registration now open: Haskell in Leipzig (Germany) December 4/5
by Johannes Waldmann 13 Nov '15

13 Nov '15

Register now - for Amazing Talks and Thrilling Tutorials: HaL-10 Haskell in Leipzig December 4/5 http://nfa.imn.htwk-leipzig.de/HAL2015/ Opens with an invited talk by Joachim Breitner on MonadFix, closes with a presentation of Liquid Haskell by Michael Beaumont. - Johannes Waldmann. PS: HaL-1 (in 2006, on quite the same day) also had a MonadFix talk. Well of course, this has something to do with recurrence...

1 0

Haskell Platform Plans
by Gershom B 13 Nov '15

13 Nov '15

Dear all, As you know, Mark has passed on the Haskell Platform maintainer hat to me. I wanted to give a heads-up on current plans to keep folks in the loop. This message has three sections, first the 7.10.3 release, next the 8.0 release, and finally some general musings on fiddly details and future plans. 1) 7.10.3 The 7.10.3 release candidates have been out for windows and unix for a bit. As I understand it there is still work underway on the mac build, but that will hopefully be coming shortly. The plan is to release a new platform roughly simultaneously. This platform will work essentially as in the past, for two reasons. First, because it is the last release in the 7.10 series and should be seen like the 7.10.3 compiler as just incorporating some necessary patches rather than any serious changes. Furthermore, the future plans underway rely on a few patches to cabal which have been merged, but are not yet in any existing cabal-install release. A few packages have received minor version bumps, as follows: PACKAGE 7.10.2-a latest ------------------------------------------- case-insensitive 1.2.0.4 1.2.0.5 fgl 5.5.2.0 5.5.2.3 GLUT 2.7.0.1 2.7.0.3 GLURaw 1.5.0.1 1.5.0.2 HUnit 1.2.5.2 1.3.0.0 OpenGL 2.12.0.1 2.13.1.0 OpenGLRaw 2.5.1.0 2.6.0.0 primitive 0.6 0.6.1.0 syb 0.5.1 0.6 scientific 0.3.3.8 0.3.4.2 StateVar 1.1.0.0 1.1.0.1 A few packages were held back due to dependency issues (notably zlib) and additionally, packages shipped with ghc were held back to the versions that will be shipped with 7.10.3. 2) 8.0 We also plan to ship a new platform concurrently with the ghc 8.0 that should be released early next year. That platform will implement some long-discussed and requested changes. First, the platform already ships with msys on windows. However, it does not do so in a way that lets you, as with minGHC, install the network library directly, or for that matter install directly other libraries that use build-type configure. This is because the msys binaries don't get placed into the path, by design. The new platform will ship with a newer cabal, incorporating a patch (pull request #2480) that uses the extra-prog-path setting for build-type: configure. This should allow network and other things reliant on build-type: configure to directly cabal install. The goal for the platform on windows will be that any packages binding to msys libraries _should_ be cabal installable without hassle. If you maintain a library that you think would be a good test-case for this, please drop a line so we can work together towards this goal. Second, the default platform will be _minimal_. That is to say that it will _only_ install into the global package database those packages that are directly shipped with ghc, and not any additional platform packages. "Blessed" platform packages will however still be shipped as a "default user cabal.config" file, so in a setting where users want to work unsandboxed, their versions of platform libs will remain pegged to those chosen by the platform, should they not choose to alter their settings. In a sandboxed setting, or in the presence of a local cabal.config generated by a freeze, those constraints will be disregarded. Furthermore, it is likely but not certain that the "nix-like cabal" or "no-reinstall cabal" will be available for the 8.0 release. If this is the case, users will be able to operate in an unsandboxed environment without conflicts, as multiple instances of the same version of a package, with different dependency choices, will be able to live side-by-side. Third, the platform will ship not only with cabal-install, but also with the stack tool, so that users can choose either workflow, depending on their project or preferences. A number of people have adopted the stack tool, and many beginners have reported success with it as well, so it will be good to provide that functionality out of the box with every platform install. Time and resources permitting we would also like to ship a platform version _with_ the platform libraries prebuilt and included, as that is also a use case that some people continue to like. However, this is a secondary priority, and contingent on us getting our build infrastructure into a good enough shape to make this not too much extra hassle. I'm excited about these changes, and confident we can get their in a timespan that matches the 8.0 release of ghc. 3) Generalities As I mentioned, it would be good to have a more uniform build infrastructure. Generally, I have put out some feelers and am working towards extending the ghc nightly buildbot infrastructure to both cover more platforms and also cover more tools -- not only ghc, but cabal, the platform, perhaps haddock, ghcjs, etc. This way we can get an economy of scale and many of our core tools will be able to all share regular automated builds across many platforms. If you like CI/buildbot systems and would like to help out with this project, please reach out. Also, once we've modernized and fixed up the core platform installer tech, it would be nice to move back to the process of making the platform a good set of blessed libraries -- taking more proposals for additions to it, looking to cull libraries that are no longer widely used, etc. As part of this I intend to move the haskell-platform list off our deprecated community.haskell.org infrastructure and onto mail.haskell.org with our other active lists. Finally, I'm happy to be maintainer of the platform through this period of change and transition, but at some future point, as things get sorted out and the release process becomes more standard and mechanical, I would very much like to pass this responsibility on. I have had some nibbles of offers, but if other people want to begin to get involved, please let me know and we can start to get small contributions from you so that you can become familiar with the various tech and systems involved. The Haskell ecosystem is a team effort, a collective project, and volunteer driven. In my modest experience hacking on the various systems involved (cabal, cabal-install, hackage, the platform build, etc.) some are a bit confusing, but I have always found helpful contributors willing to explain things and review patches, and to help think about and diagnose problems. And none of the code has been as confusing as things I've had to wade through for employment-related purposes :-). So when this stuff doesn't work as well as we'd like, we can investigate together, and then put our heads together and figure out how to improve it together. Furthermore, it can be very satisfying to do so, because the impact of those improvements makes itself widely felt. I look forward to more people joining in! Best, Gershom

1 0

Re: [Haskell-cafe] haskell-src-exts maintenance
by Matthew Pickering 12 Nov '15

12 Nov '15

Peter, Please can you do the release. I completed the work updating HSE several months ago, a much better version of HSE has been waiting on the master branch since then. I thank you for providing helpful review for the patches I submitted but since then I have sent three emails asking about the release. After the second you promised to do a release at the end of October but that never happened. It is a shame that the user's of HSE have had to live with many long standing bugs when they have been fixed for months. If you can not do it for whatever reason then please can you add me as a maintainer on hackage and the github repo so that users can get an updated version of HSE. Best wishes, Matt On Tue, Jul 28, 2015 at 11:35 PM, Peter A Jonsson <jonsson.peter.a(a)gmail.com> wrote: > I’m not even going to bother to CC haskell-cafe since that will just bounce or go into a black hole. > > I exchanged a couple of mails with David (Lemmih) and my impression was that he was going to act upon some things but I didn’t follow up on that so there was probably some miscommunication between the two of us. > > I’ve merged some things and reviewed some patches. I agree with Neil that stable things should be merged and the yearly release of HSE should be made. I don’t want to rush things out through the door at any cost though—I believe HSE’s users are better served by something that is a strict improvement and contains more features than the last release compared to something that has even more features but is a bit shaky and requires a new major version of HSE in just a month or two which would force the client code to be re-tested and re-released. > > Best Wishes, > > Peter > >> On 28 Jul 2015, at 17:49, Neil Mitchell <ndmitchell(a)gmail.com> wrote: >> >> As a very heavy HSE user (HLint and Hoogle), who has had a reasonably >> close working relationship with all of Niklas (my SoC mentor and my >> SoC mentee), Roman and Peter (a fellow supercompiler developer) and >> Matt (currently hacking on HLint), I thought I should weigh in. >> >> The current state of HSE is a little forlorn - there are 22 open pull >> requests, everything from reducing algorithm complexity (an accidental >> n^3), fixing the default encoding (should be UTF8) and lots of actual >> parser fixes. A lot of this is good stuff, and the high level of >> external contributions is a really good sign. But they need to be >> merged and reviewed, and it seems the bandwidth just isn't there at >> the moment. Given Matt's comments on the existing tickets, and the >> triage he's already performing on the repo, I have high hopes that >> Matt could provide a bit more of the time and attention. Peter, >> perhaps a co-maintainer would be good for a little while? >> >>> If it's not soon then please could you add myself and Christian to the >>> maintainers so that we can perform some short term maintenance. My >>> immediate plan of action would be >>> >>> 1. Immediately cut a 1.17 release from the master branch as it >>> contains much better parsing of lifted constructors which are becoming >>> more prevalent. >>> 2. Review and merge recent pull requests. >>> 3. Update the parser as far as possible with missing features. >>> 4. Release 1.18 with these improvements within 1 month. >> >> Awesome! Although as a preference I'd go for as much of 2 as you can >> in a couple of days before doing 1 - a lot of the patches are simple >> and valuable, and a 2 day wait isn't going to be too problematic. >> >> Thanks, Neil >

1 0

checking whether the list is active
by Miroslav Kocic 12 Nov '15

12 Nov '15

3 2

types calculation
by Dmitry Olshansky 11 Nov '15

11 Nov '15

Hello! It seems that types without parameters are not reduced in ghc unlike CAFs. I.e. if we have type T1 a b = ... type T2 = T1 Int Int than T2 will be calculated on each utilization. Is my statement correct? If so, why is it? With complicated type-calculation compile time is growing too fast. Best regards, Dmitry

2 4

Stack: Copying possible?
by Rustom Mody 11 Nov '15

11 Nov '15

Trying to switch over to stack I copied over ~/.stack to another Linux box And it gives me sanity check failed Machines are same -- both 64 bit ubuntu wily -- user-names are different and that shows in the error message. I'd like to avoid almost a Gb of repeated downloads if possible. But if thats not kosher that fine... Just asking :-)

3 4

Question, re: illegal instance error.
by David Banas 11 Nov '15

11 Nov '15

Hi all, I don’t understand why this code: 50: instance (IsNat n, RealFloat a) => FFT (RTree n) a where is generating this error: fft_test.hs:50:36: Illegal instance declaration for ‘FFT (RTree n) a’ (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) In the instance declaration for ‘FFT (RTree n) a’ and was hoping someone could help me get it. Thanks! -db

3 2