- Haskell-Cafe - Haskell.org

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 21 Nov '15

21 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 21 Nov '15

21 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 21 Nov '15

21 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 21 Nov '15

21 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 21 Nov '15

21 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 21 Nov '15

21 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