- Haskell-Cafe - Haskell.org

VerifyThis 2018: Call for Problems and First Announcement
by Andrei Paskevich 21 Feb '18

21 Feb '18

******************************************************************************* VerifyThis Verification Competition 2018 FIRST ANNOUNCEMENT AND CALL FOR PROBLEMS Competition to be held at ETAPS 2018 http://verifythis.ethz.ch ******************************************************************************** Get involved, even if you cannot participate in the competition: provide a challenge. IMPORTANT DATES Submission deadline: March 9, 2018 Competition: April 14 and 15, 2018 CALL FOR PROBLEMS To extend the problem pool, we are now soliciting algorithms and data structures which could contribute interesting verification challenges for the VerifyThis program verification competition (itself introduced below). We encourage suggestions at any level of detail, in particular submissions without a fully worked out verification task. - a problem may contain an informal statement of the algorithm to be implemented (optionally with complete or partial pseudocode) and the requirement(s) to be verified - a problem should be suitable for a 60-90 minute time slot - submission of reference solutions is welcome but not mandatory - problems with an inherent language- or tool-specific bias should be clearly identified as such - problems that contain several subproblems or other means of difficulty scaling are especially welcome - the organizers reserve the right (but no obligation) to use the problems in the competition, either as submitted or with modifications - submissions from (potential) competition participants are allowed Problems from previous competitions can be seen at http://verifythis.ethz.ch Submissions are to be sent by email to verifythis(a)cs.nuim.ie by the date indicated above. PRIZES The most suitable submission for competition will receive a prize. ABOUT VerifyThis 2018 will take place as part of the European Joint Conferences on Theory and Practice of Software (ETAPS 2018) on April 14 and 15, 2018. It is the 7th event in the VerifyThis competition series. Information on previous events and participants can be found at http://verifythis.ethz.ch The aims of the competition are: - to bring together those interested in formal verification, and to provide an engaging, hands-on, and fun opportunity for discussion - to evaluate the usability of logic-based program verification tools in a controlled experiment that could be easily repeated by others. The competition will offer a number of challenges presented in natural language. Participants have to formalize the requirements, implement a solution, and formally verify the implementation for adherence to the specification. There are no restrictions on the programming language and verification technology used. The correctness properties posed in problems will have the input-output behaviour of programs in focus. Solutions will be judged for correctness, completeness and elegance. ORGANIZERS * Marieke Huisman, University of Twente, the Netherlands * Rosemary Monahan, Maynooth University, Ireland * Peter Müller, ETH Zürich, Switzerland * Andrei Paskevich, Paris-Sud University, France * Gidon Ernst, National Institute of Informatics Tokyo, Japan CONTACT Email: verifythis(a)cs.nuim.ie Web: http://verifythis.ethz.ch

1 0

Arrow laws of Netwire
by KAction＠gnu.org 20 Feb '18

20 Feb '18

Hello! In process of adapting 'netwire-5.0.0' to my needs I discovered following strange thing. Let us consider following simple program: {-# LANGUAGE Arrows #-} import FRP.Netwire import Data.Monoid -- I almost sure this is correct, since it is copied -- from "Programming with Arrows", J. Hughes mapA :: (ArrowChoice a) => a b c -> a [b] [c] mapA f = proc input -> case input of [] -> returnA -< [] z:zs -> do y_ <- f -< z ys_ <- mapA f -< zs returnA -< y_:ys_ mconcatA :: (ArrowChoice a, Monoid m) => a b m -> a [b] m mconcatA f = mapA f >>> arr mconcat -- Note the commented line. wire :: (Monad m, HasTime t s) => Wire s () m a Double wire = pure (Sum 1.0) -- >>> arr (: []) >>> mconcatA returnA >>> arr getSum >>> integral 10 main = testWire (countSession_ 1) wire Problem is that, compiled with ghc-8.0.1 this program hangs if I uncomment second line in body of ``wire`` function[1], which is wierd, since assuming monoid and arrow laws, I believe -- (Arrow a, Monoid e) => a e e arr (: []) >>> mconcatA returnA = returnA Is it false? Any suggestions? .. [1] with that line commented program works and prints sequence of numbers, with every next over previous.

5 13

Tsuru is hiring
by Mikhail Baykov 20 Feb '18

20 Feb '18

Tsuru Capital is hiring, full time and intern positions are available. Haskell knowledge is required, experience with pricing futures/options would be nice but not necessary. Located in Tokyo, company language is English. Casual environment, nice monitors and a big coffee machine. Details how to apply are on our website: http://www.tsurucapital.com/en/ Feel free to ask questions here, in email or #tsurucapital on freenode.

1 0

ANN: stack-1.6.5
by Emanuel Borsboom 20 Feb '18

20 Feb '18

See https://haskellstack.org for installation and upgrade instructions. This is a bug-fix release. Bug fixes: * 1.6.1 introduced a change that made some precompiled cache files use longer paths, sometimes causing builds to fail on windows. This has been fixed. See [#3649](https://github.com/commercialhaskell/stack/issues/3649) * Some unnecessary rebuilds when no files were changed are now avoided, by having a separate build cache for each component of a package. See [#3732](https://github.com/commercialhaskell/stack/issues/3732). * Correct the behavior of promoting a package from snapshot to local package. This would get triggered when version bounds conflicted in a snapshot, which could be triggered via Hackage revisions for old packages. This also should allow custom snapshots to define conflicting versions of packages without issue. See [Stackage issue #3185](https://github.com/fpco/stackage/issues/3185). * When promoting packages from snapshot to local, we were occassionally discarding the actual package location content and instead defaulting to pulling the package from the index. We now correctly retain this information. Note that if you were affected by this bug, you will likely need to delete the binary build cache associated with the relevant custom snapshot. See [#3714](https://github.com/commercialhaskell/stack/issues/3714). * `--no-rerun-tests` has been fixed. Previously, after running a test we were forgetting to record the result, which meant that all tests always ran even if they had already passed before. See [#3770](https://github.com/commercialhaskell/stack/pull/3770). * Includes a patched version of `hackage-security` which fixes both some issues around asynchronous exception handling, and moves from directory locking to file locking, making the update mechanism resilient against SIGKILL and machine failure. See [hackage-security #187](https://github.com/haskell/hackage-security/issues/187) and [#3073](https://github.com/commercialhaskell/stack/issues/3073). Thanks to all our contributors for this release: * Arnaud Spiwack * Artyom * Artyom Kazak * Charles Reilly * Dave Tapley * Emanuel Borsboom * Joshua Simmons * Luke Murphy * Michael Sloan * Michael Snoyman * Nicolas Mattia * Paolo G. Giarrusso * Samuel Lelièvre * Simon Hengel * Thomas Broadley * tswelsh

1 0

Replace data constructors via meta programming
by Vilem-Benjamin Liepelt 18 Feb '18

18 Feb '18

Hi, I am looking for a solution to get rid of this silly boilerplate: eval :: Ord var => Map var Bool -> Proposition var -> Bool eval ctx prop = evalP $ fmap (ctx Map.!) prop where evalP = \case Var b -> b Not q -> not $ evalP q And p q -> evalP p && evalP q Or p q -> evalP p || evalP q If p q -> evalP p ==> evalP q Iff p q -> evalP p == evalP q What I would like to do in essence is to replace the data constructors like so: -- Not valid Haskell!! Can't pattern match on constructor only... magic = \case Var -> id Not -> not And -> (&&) Or -> (||) If -> (==>) Iff -> (==) compile = transformAST magic $ fmap (\case 'P' -> False; 'Q' -> True) >>> compile (Iff (Not (And (Var 'P') (Var 'Q'))) (Or (Not (Var 'P')) (Not (Var 'Q')))) ((==) (not ((&&) (id True) (id False))) ((||) (not (id True)) (not (id False)))) Note how the compiled expression exactly mirrors the AST, so there should be some meta programming technique for this. Does anyone have an idea how I can achieve this? The full source code is here: https://gist.github.com/vimuel/7dcb8a9f1d2b7b72f020d66ec4157d7b I am happy to take any other comments relating to my code... Best, Vilem

10 16

MonadComprehensions madness
by Albert Y. C. Lai 17 Feb '18

17 Feb '18

I am just starting to learn MonadComprehensions and I'm following its type rules to their logical conclusion. So I can have [ x | x <- "abc", then group by EXPR using PNT ] where EXPR is an expression of my choosing, PNT is a function of type forall a. (a -> E) -> [a] -> M (F a) where E is the type of EXPR, M is a Monad instance of my choosing, and F is a Functor instance of my choosing. (And even the [a] can be replaced by N a, as long as "abc" has type N Char.) (My freedom over M and F isn't quite documented in the GHC user's guide, but there is very little you can't discover by putting a few typed holes here and there >:) ) So I choose EXPR = ord x, E = Int, M = IO, F = IntMap, so I can have: {-# LANGUAGE MonadComprehensions, TransformListComp #-} module F where import Data.Char (chr, ord) import qualified Data.IntMap.Strict as IntMap foo :: IO (IntMap.IntMap Char) foo = [ x | x <- "a\r\n", then group by ord x using whee ] whee :: (a -> Int) -> [a] -> IO (IntMap.IntMap a) whee f xs = do print (map (chr . f) xs) return (IntMap.fromList (zip (map f xs) (reverse xs))) Warning: I have only proved that it type-checks; I have not understood what good it does. >:)

1 0

web framework
by Dennis Raddle 16 Feb '18

16 Feb '18

I'd like a recommendation for a way to write web apps in Haskell. Background: I have written code in Python, C++ and Haskell for many years. However I have done no substantial web programming. My goal is mathematics-education-themed apps to run on browsers on any device. At first I'll be happy to run the app on my laptop and connect locally with an iPad or smartphone while I sit with my students. Later I may deploy it at scale "in the cloud" (I mean anyone connected to the internet can run it, and the servers belong to the hosting provider). Why a browser app? I figure it's the best way to get a portable app that will run on phones, tablets, and computers of all OS's. Why Haskell? The goal right now is fast prototyping and experimentation, especially for some fairly complex algorithms. I spent some time with JavaScript, TypeScript, and Scala.JS. I'm just so much more comfortable in Haskell with which I can write clean & sophisticated algorithms quickly. I see lots of mentions of Haskell "platforms" and "stacks" etc. on the Haskell Wiki. But I will confess I don't really know what a "platform" or "stack" is, or which of the options will support my needs. I know close to zero about apps in the browser. Regarding my UI needs, my app will have lots of graphics and lots of things to click on, drag, etc. It will need to be touch-screen responsive. Dennis

5 6

GHC 8.2.2 for WSL Ubuntu 16.04
by Yitzchak Gale 14 Feb '18

14 Feb '18

I have made available a build of GHC 8.2.2 with the config option: --disable-large-address-space You may find this useful if you are using Ubuntu 16.04 on Windows Subsystem for Linux. https://github.com/zoominsoftware/ghc-8.2.2-wsl Although Microsoft has been making gradual progress on the large address mapping issue[1][2], and the situation is much improved, there is still an extra startup latency of about 13 secs. for applications that pre-map a large address space as GHC does by default. This makes the standard GHC 8.2.2 binary unusable for compiling projects of any non-trivial size on WSL. You may find this GHC 8.2.2 binary more usable. Regards, Yitz [1] https://ghc.haskell.org/trac/ghc/ticket/13304 [2] https://github.com/Microsoft/WSL/issues/1671

4 5

Haskell future and UTF8 vs UTF-16
by Alan & Kim Zimmerman 13 Feb '18

13 Feb '18

Hi all What is the current and future status of UTF8 vs UTF-16 in the haskell world? I understand that currently Text uses UTF-16, and it is used generally because of compatibility requirements in the Microsoft ecosystem, but that there are movements afoot to move to a UTF8 only environment at some unspecified future point. The question arises as I ponder a pull request on haskell-lsp to switch to a UTF-16 based library[1] Alan [1] https://github.com/alanz/haskell-lsp/pull/70

8 7

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 174, Issue 13
by Mikhail Baykov 13 Feb '18

13 Feb '18

recursion-schemes package might do the trick. I wrote TH for it and somebody took care of getting it merged in. It should simplify some of this boilerplate. > > I am looking for a solution to get rid of this silly boilerplate: > > eval :: Ord var => Map var Bool -> Proposition var -> Bool > eval ctx prop = evalP $ fmap (ctx Map.!) prop > where > evalP = \case > Var b -> b > Not q -> not $ evalP q > And p q -> evalP p && evalP q > Or p q -> evalP p || evalP q > If p q -> evalP p ==> evalP q > Iff p q -> evalP p == evalP q > > What I would like to do in essence is to replace the data constructors like so: > > -- Not valid Haskell!! Can't pattern match on constructor only... > magic = \case > Var -> id > Not -> not > And -> (&&) > Or -> (||) > If -> (==>) > Iff -> (==) > > compile = transformAST magic $ fmap (\case 'P' -> False; 'Q' -> True) > >>>> compile (Iff (Not (And (Var 'P') (Var 'Q'))) (Or (Not (Var 'P')) (Not (Var 'Q')))) > ((==) (not ((&&) (id True) (id False))) ((||) (not (id True)) (not (id False)))) > > Note how the compiled expression exactly mirrors the AST, so there should be some meta programming technique for this. > > Does anyone have an idea how I can achieve this? > > The full source code is here: https://gist.github.com/vimuel/7dcb8a9f1d2b7b72f020d66ec4157d7b

2 1

How do you turn off GHC flags?
by Christopher Done 13 Feb '18

13 Feb '18

If I run :set -fdeferred-type-errors in GHCi, how do I turn it off again? I tried -f-deferred-type-errors and -fno-deferred-type-errors and neither are recognized. Cheers

2 3

Proposal for GHC: global HasFoo classes
by KAction＠gnu.org 13 Feb '18

13 Feb '18

Hello! I have idea for GHC to make working with lenses even more convenient. # Rationale Let us recall, that "type Lens' a b = (a -> f a) -> (b -> f b)" is about accessing some value of type `a' somewhere deep in value of type `b'. Let us consider that we have following datatypes: -- module 1 {-# LANGUAGE DisambiguateRecordFields #-} data Foo = Foo { _a :: Int, _b :: Double } data Bar = Bar { _a :: Double, _c :: Char } Since we want to be able to use 'a' as both lens into 'Foo' and into 'Bar', we would use 'makeFields' function from 'lens' package, and get something like this generated (implementation is omited): -- module 1 class HasA w p | w -> p where a :: Lens' w p class HasB w p | w -> p where b :: Lens' w p class HasC w p | w -> p where c :: Lens' w p instance HasA Foo Int instance HasA Bar Double instance HasB Foo Double instance HasC Bar Char It is all great and convenient, but what if we have another module with -- module 2 data Quiz = Quiz { _a :: Bool } In same spirit, 'makeFields' will create -- module 2 class HasA w p | w -> p where a :: Lens' w p instance HasA Quiz Bool Now, you import unqualified both modules, and you have two versions of 'a' function, one per module. From GHC's point of view, class HasA in module 1 and module 2 are different, while we, humans, understand, that they are not. To mitigate this problem, common convention is to collect all types, used in package, and their lenses in signle module. But there is no solution {as far as I know} for lenses from different packages. # Proposal Let us introduce a new extension -XGlobalLensClasses (better name is welcome). When this extension is activated in module, you can write instances like instance HasFoo Foo Int where foo = -- apporiate lens with following implicit class definition: class HasFoo w p | w -> p where foo :: Lens' w p After that, module can export 'foo'. All implicit HasFoo classes, whose instances are defined in different modules are considered the same. It eliminates problem, described in rationale if both modules in consideration used proposed extension. It should be noted, that this extension would not disrupt any existing code, although in distant future we could have it by default. # Alternative idea The proposal of making global only one particular class namespace 'Has<Foo>' with very specific signature is not generic enough. Maybe we can add option to mark class definition as global instead, merging all global classes with same signature together? Sounds more complicated, but this solution will not upset those people who disagree with Lens-based HasFoo classes. Opinions?

3 2

Midlands Graduate School 2018 - registration now open!
by Graham Hutton 13 Feb '18

13 Feb '18

Dear all, Midlands Graduate School (MGS) registration is now open! Eight courses on dependently typed programming, category theory, lambda calculus, denotational semantics, and more. 9-13 April 2018, Nottingham, UK. Spaces are limited, so early registration is recommended. Please share! http://tinyurl.com/MGS18NOTT Best wishes, Graham Hutton and Henrik Nilsson ========================================================== *** CALL FOR PARTICIPATION *** Midlands Graduate School 2018 9-13 April 2018, Nottingham, UK http://tinyurl.com/MGS18NOTT BACKGROUND: The Midlands Graduate School (MGS) in the Foundations of Computing Science provides an intensive course of lectures on the mathematical foundations of computing. The MGS has been running since 1999, and is aimed at PhD students in their first or second year of study, but the school is open to everyone, and has increasingly seen participation from industry. We welcome participants from all over the world! COURSES: Eight courses will be given. Participants usually take all the introductory courses and choose additional options from the advanced courses depending on their interests. Invited course - Type-Driven Development with Idris, Edwin Brady Introductory courses - Lambda Calculus, Venanzio Capretta - Category Theory, Roy Crole - Domain Theory and Denotational Semantics, Achim Jung Advanced courses - Univalent Foundations, Benedikt Ahrens - Coalgebra, Alexander Kurz - Separation Logic, Georg Struth - Machine Learning, Michel Valstar REGISTRATION: Registration is £550 for student, academic and independent participants, and £850 for industry participants. The fee includes 5 nights single en-suite accommodation (Sun-Thu), lunch and coffee breaks, and the conference dinner. The registration deadline is Friday 16th March. Spaces are limited, so please register early to secure your place. SPONSORSHIP: We offer a range of sponsorship opportunities for industry (bronze, silver and gold), each with specific benefits. Please see the website for further details. ========================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

Re: [Haskell-cafe] Replace data constructors via meta programming
by Olaf Klinke 12 Feb '18

12 Feb '18

Vilem, I suggest to use free monads. They reduce boilerplate a little. First, separate the variable form the rest of the syntax: data Prop v = Not v | And v v | Or v v | If v v | Iff v v -- maybe GHC can derive this instance for you, given the appropriate language extension flag. instance Functor Prop where fmap f (Not p) = Not (f p) fmap f (And p q) = And (f p) (f q) fmap f (Or p q) = Or (f p) (f q) fmap f (If p q) = If (f p) (f q) fmap f (Iff p q) = Iff (f p) (f q) Then use Control.Monad.Free from the package 'free'. It also has a template Haskell part. The function you want is called 'iter' there, and applying a context of type var -> Bool is simply fmap. Note that a Map from var to Bool does not always yield a total reduction, since your formula might contain variables that are not in the Map. data Free f var = Pure var | Free (f (Free f var)) instance Functor f => Monad (Free f) where return = Pure Pure a >>= f = f a Free m >>= f = Free (fmap ((=<<) f) m) type Proposition var = Free Prop var type Predicate = Free Prop Bool -- F-algebras for functor f class Functor f => FAlg f a where alg :: f a -> a instance FAlg Prop Bool where alg (Not b) = not b alg (And p q) = p && q alg (Or p q) = p || q alg (If p q) = not p || q alg (Iff p q) = p == q eval = iter alg :: Predicate -> Bool map_and_eval ctx = iter alg . fmap ctx If feasible, remove If and Iff from the Prop type and make them binary functions on type Proposition var instead. That reduces the boilerplate further. -- Olaf

1 0

GHC/GHCi
by Vladyslav Nikolayevich 10 Feb '18

10 Feb '18

Hi, GHCi https://hackage.haskell.org/package/ghc-8.2.1/docs/GHCi.html doc says that: `Interacting with the interpreter, whether it is running on an external process or in the current process.` but where I can get some examples haw to “connect” to the already running ghci, do some staff and reload ghci session them? -- С уважением, Владислав Ищенко

2 1

mistaken post
by Doug McIlroy 10 Feb '18

10 Feb '18

Apologies for my off-topic post about shell programming yesterday. (I replied to the wrong message in my inbox.) Doug

2 1

[JOBS] Formal methods positions at Intel
by Levent Erkok 09 Feb '18

09 Feb '18

We have two open positions in formal methods/verification at our team at Intel: http://jobs.intel.com/ShowJob/Id/1504155/Sr.-Formal-Verification-Engineer/ While the work centers around formal-verification of Intel's microprocessor offerings, people with background in functional programming and generally interested in correctness proofs of both software and hardware would be well suited. SAT/SMT solving, BDDs, Model-checking are most commonly occurring terms you hear on a daily basis. Feel free to contact me in private for questions, or send me your CV. Cheers, -Levent.

1 0

Profiling code using tagsoup
by Fabien R 08 Feb '18

08 Feb '18

Hello, I have troubles profiling my EPG grabber. The profile log is: -------------------------- Thu Feb 8 17:14 2018 Time and Allocation Profiling Report (Final) tv_grab_fr +RTS -pa -hc -i1 -RTS --days 1 --output-file /res.xml total time = 103.35 secs (103353 ticks @ 1000 us, 1 processor) total alloc = 7,602,130,080 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc ticks bytes GC GC <built-in> 50.5 0.0 52166 57504 parse Text.HTML.TagSoup.Specification src/Text/HTML/TagSoup/Specification.hs:35:1-19 15.4 15.2 15879 1159030944 output Text.HTML.TagSoup.Implementation src/Text/HTML/TagSoup/Implementation.hs:(80,1)-(142,44) 13.5 22.9 14000 1743780696 expand Text.HTML.TagSoup.Implementation src/Text/HTML/TagSoup/Implementation.hs:(49,1)-(60,30) 11.6 39.0 11976 2962740856 -------------------------- Further in the log, I see: TvGrabPrograms.mySccGetProgramDetails TvGrabPrograms src/TvGrabPrograms.hs:69:1-17 5000 19 0.6 2.2 42.3 79.2 640 165979512 ~/= Text.HTML.TagSoup src/Text/HTML/TagSoup.hs:103:1-25 5543 135987 0.1 0.0 28.5 44.4 54 3263688 ~== Text.HTML.TagSoup src/Text/HTML/TagSoup.hs:(87,1)-(99,21) 5544 135987 0.5 0.3 28.4 44.3 485 19485856 parseTags Text.HTML.TagSoup.Parser src/Text/HTML/TagSoup/Parser.hs:16:1-41 5545 135987 0.0 0.0 27.9 44.1 44 0 parseTagsOptions Text.HTML.TagSoup.Parser src/Text/HTML/TagSoup/Parser.hs:25:1-39 5546 135987 0.1 0.1 27.9 44.1 138 7615272 parseTagsOptions Text.HTML.TagSoup.Manual src/Text/HTML/TagSoup/Manual.hs:12:1-54 5547 135987 0.4 0.3 27.7 44.0 422 22845912 output Text.HTML.TagSoup.Implementation src/Text/HTML/TagSoup/Implementation.hs:(80,1)-(142,44) 5548 135987 8.0 13.1 8.0 13.2 8221 994675336 -------------------------- But I see no function (~/=) calling (~==) calling parseTags in my code. The only line using parseTags is: let !tl = parseTags $ L8.unpack $ responseBody httpRsp Did I miss something ? Thanks in advance, Fabien

2 1

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 174, Issue 9
by Doug McIlroy 08 Feb '18

08 Feb '18

Thanks for the quidk reply. Please do send info about local arrangements. All I know is the dates. I read your shell assignment (but haven't yet looked at your program). It's a very good model of real life with Unix, particularly in regard to data laundry: automate what you can, but check the results. And that often feeds back into insight about further automation. I was once doing just such a job (in this case, trying to devise pronunciation rules for a text-to-speech system) when I got tired of using an editor to scan a dictionary that was too big to fit. I asked Ken Thompson if he could extract the editor's regular-expression recognizer into a free standing program. It turned out he had already done so for his own private use. Thus did grep make its appearance among Unix tools. Incidentally, you suggest using sed to get rid of carriage returns, disguised as ^M--very confusing because as a regular expression ^M means an M at the beginning of a line. The simplest solution I know is tr -d '\r'. For another revealing shell exercise you may like http://www.cs.dartmouth.edu/~doug/sieve.pdf. The shell stuff begins on page 4. Then comes truly lovely code in Haskell. Doug

1 0

Re: [Haskell-cafe] avoiding parens in postfix applicative notation
by Johannes Waldmann 08 Feb '18

08 Feb '18

for reference, previous discussion at https://mail.haskell.org/pipermail/libraries/2017-February/027685.html On whether to put <&> in Data.Functor. Will this happen? - J.W.

1 0

Re: [Haskell-cafe] avoiding parens in postfix applicative notation
by Johannes Waldmann 07 Feb '18

07 Feb '18

Thanks for comments and suggestions. > The lens library defines (<&>) with very low precedence Yes. I guess my question was: Why? > f <$> foo <*> bar where f x y = ... I avoid "where" because * it uses an identifier before it is defined * it is not as composable as "let", which is an expression, but "where" can only be attached to declarations - I can write 1 + let x = 3 in x but not 1 + ( x where x = 3 ) - J.W.

1 0

avoiding parens in postfix applicative notation
by Johannes Waldmann 07 Feb '18

07 Feb '18

Dear Cafe - operators <$> and <*> have their precedence so that this (silly example) works without parens: (,) <$> "foo" <*> "bar" Most of the time, I find that the function (the first argument) is the largest sub-expression, so I want to put it last. I can do this import Control.Lens.Lens ((<&>)) "foo" <**> ( "bar" <&> (,) ) but (even ignoring that this pulls in a library with a ton of dependencies) this needs parens, and I find this quite ugly when the closing parenthesis comes at the end of lambda expression that spans several lines. One work-around is ( "foo" <**> ) $ "bar" <&> (,) Can this be done in a less noisy way? - J.W. PS: Bike-sheddingly, shouldn't this (<&>) be defined right next to (<$>) ? There's nothing that would tie it to lenses? And, (&) right next to ($) ?

4 3

[ANNOUNCE] GHC 8.4.1-alpha3 available
by Ben Gamari 06 Feb '18

06 Feb '18

The GHC development team is pleased to announce the third and likely last alpha release leading up to GHC 8.4.1. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha3 Due to user demand we now offer a binary distribution for 64-bit Fedora 27, which links against ncurses6. This is in contrast to the Debian 8 distribution, which links against ncurses5. Users of newer distributions (Fedora 27, Debian Sid) should use this new Fedora 27 distribution. Also due to user demand we have reintroduced compatibility with GCC 4.4, which earlier alphas had dropped due to #14244. Note that this release is still affected by #14675, wherein the compiler will segmentation fault when built with some Ubuntu toolchains. We are actively working to identify the cause and hope that this will be resolved before the final release. === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes into users' hands and more quickly identify potential issues. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

1 0

Re: [Haskell-cafe] rolling span and groupBy for lists
by Harendra Kumar 05 Feb '18

05 Feb '18

On 5 February 2018 at 12:22, Evan Laforge <qdunkan(a)gmail.com> wrote: > I have my own list library with a bunch of things like this. I think > it's what most people do, and some upload them to hackage, e.g. > utility-ht or the split package, or data-ordlist. > The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes more time to discover it than writing your own. And then uploading what you wrote to hackage compounds the problem. A hoogle search only shows the groupBy in base, signature search also does not yield other results, it seems hoogle does not cover those other packages. After writing my own and spending quite a bit of time I could find two other similar implementations of groupBy, one in "utility-ht" package and the other in "data-list-sequences" but they don't turn up in hoogle search. It looks like hoogle database should cover more packages, or maybe the search has some issues. This state of affairs encourages people to write their own rather than find and reuse stuff. My example in this email can be dismissed as a small one but I think it is a larger problem. > You can probably find something like this in 'split', or if not, that > might be a good place to contribute it. > Yes, that is the fallback option I was considering, split seems to be the most comprehensive of all such list related packages. > I have a bunch of grouping functions too, which I use all the time, so > if there's some kind of general list grouping package then maybe I > could put them there. > It will be a great service to other Haskell explorers if we can consolidate all such packages and make one standard package covering most use cases and deprecate the other packages. Also it may be a good idea to have a see-also or related packages kind of field in packages so that discovery is easy. > On the other hand, this sort of thing is pretty individual, so it > doesn't seem so bad for each person to have their own local library. > That way you know it fits your style. Ultimately I think that's why > none of the split functions made it into Data.List, every person has a > slightly different idea of what it should be. > I thought that rollingGroupBy would have been a better default option as it can practically subsume the purpose of groupBy. groupBy in base is not well documented, and intuitively many think it works the way rollingGroupBy works i.e. compare two successive elements rather than comparing a fixed element. See this stack overflow question https://stackoverflow.com/questions/45654216/haskell-groupby-function-how-e… , I thought the same way. I guess if we compare two successive elements, by transitive equality the existing groupBy implementation will practically get covered by that, not strictly compatible but should serve all practical purposes. That was the point why I was asking to consider having it in base alongside groupBy. It seems more useful, general and intuitive than the existing groupBy. -harendra > > On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar <harendra.kumar(a)gmail.com> > wrote: > > Hi, > > > > For a small problem, I was looking for a groupBy like function that > groups > > based on a predicate on successive elements but I could not find one. I > > wrote these little functions for that purpose: > > > > -- | Like span, but with a predicate that compares two successive > elements. > > The > > -- span ends when the two successive elements do not satisfy the > predicate. > > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) > > rollingSpan _ xs@[] = (xs, xs) > > rollingSpan _ xs@[_] = (xs, []) > > rollingSpan p (x1:xs@(x2:_)) > > | p x1 x2 = > > let (ys, zs) = rollingSpan p xs > > in (x1 : ys, zs) > > | otherwise = ([x1], xs) > > > > -- | Like 'groupBy' but with a predicate that compares two successive > > elements. > > -- A group ends when two successive elements do not satisfy the > predicate. > > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] > > rollingGroupBy _ [] = [] > > rollingGroupBy cmp xs = > > let (ys, zs) = rollingSpan cmp xs > > in ys : rollingGroupBy cmp zs > > > > Are there any existing functions that serve this purpose or is there any > > simpler way to achieve such functionality? If not, where is the right > place > > for these, if any. Can they be included in Data.List in base? > > > > Thanks, > > Harendra > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > >

4 7

WST 2018 - 1st Call for Papers (submission: April 15, 2018)
by Salvador Lucas 05 Feb '18

05 Feb '18

========================================================================== WST 2018 - Call for Papers 16th International Workshop on Termination July 18-19, 2017, Oxford, United Kingdom http://wst2018.webs.upv.es/ ========================================================================== The Workshop on Termination (WST) traditionally brings together, in an informal setting, researchers interested in all aspects of termination, whether this interest be practical or theoretical, primary or derived. The workshop also provides a ground for cross-fertilization of ideas from the different communities interested in termination (e.g., working on computational mechanisms, programming languages, software engineering, constraint solving, etc.). The friendly atmosphere enables fruitful exchanges leading to joint research and subsequent publications. The workshop is held as part of the 2018 Federated Logic Conference (FLoC 2018) http://www.floc2018.org/ IMPORTANT DATES: * submission deadline: April 15, 2018 * notification: May 15, 2018 * final version due: May 31, 2018 * workshop: July 18-19, 2018 TOPICS: The 16th International Workshop on Termination welcomes contributions on all aspects of termination. In particular, papers investigating applications of termination (for example in complexity analysis, program analysis and transformation, theorem proving, program correctness, modeling computational systems, etc.) are very welcome. Topics of interest include (but are not limited to): * abstraction methods in termination analysis * certification of termination and complexity proofs * challenging termination problems * comparison and classification of termination methods * complexity analysis in any domain * implementation of termination methods * non-termination analysis and loop detection * normalization and infinitary normalization * operational termination of logic-based systems * ordinal notation and subrecursive hierarchies * SAT, SMT, and constraint solving for (non-)termination analysis * scalability and modularity of termination methods * termination analysis in any domain (lambda calculus, declarative programming, rewriting, transition systems, etc.) * well-founded relations and well-quasi-orders COMPETITION: Since 2003, the catalytic effect of WST to stimulate new research on termination has been enhanced by the celebration of the Termination Competition and its continuously developing problem databases containing thousands of programs as challenges for termination analysis in different categories, see http://termination-portal.org/wiki/Termination_Competition In 2018, the Termination Competition will run in parallel with FLoC 2018. More details will be provided in a dedicated announcement on the competition. PROGRAM COMMITTEE: Cristina Borralleras - U. de Vic Ugo Dal Lago - U. degli Studi di Bologna Carsten Fuhs - Birkbeck, U. of London Samir Genaim - U. Complutense de Madrid Juergen Giesl - RWTH Aachen Raul Gutiérrez - U. Politecnica de València Keiichirou Kusakari - Gifu University Salvador Lucas (chair) - U. Politecnica de Valencia Fred Mesnard - U. de La Reunion Aart Middeldorp - U. of Innsbruck Albert Rubio - U. Politecnica de Catalunya Rene Thiemann - U. of Innsbruck Caterina Urban - ETH Zürich INVITED SPEAKERS: tba SUBMISSION: Submissions are short papers/extended abstracts which should not exceed 5 pages. There will be no formal reviewing. In particular, we welcome short versions of recently published articles and papers submitted elsewhere. The program committee checks relevance and provides additional feedback for each submission. The accepted papers will be made available electronically before the workshop. Papers should be submitted electronically via the submission page: https://easychair.org/conferences/?conf=wst2018 Please, use LaTeX and the LIPIcs style file http://drops.dagstuhl.de/styles/lipics/lipics-authors.tgz to prepare your submission.

1 0

Yesod with lts-10.4
by Yotam Ohad 05 Feb '18

05 Feb '18

Hi, I'm trying to install yesod using stack and lts-10.4, but I get the following result: stack install yesod aeson-1.2.3.0: configure aeson-1.2.3.0: build Progress: 1/26 -- While building custom Setup.hs for package aeson-1.2.3.0 using: /home/yotam/.stack/setup-exe-cache/i386-linux-nopie/Cabal-simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0 build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Logs have been written to: /home/yotam/TheMafsidan/.stack-work/logs/aeson-1.2.3.0.log Configuring aeson-1.2.3.0... Preprocessing library for aeson-1.2.3.0.. Building library for aeson-1.2.3.0.. [ 1 of 24] Compiling Data.Aeson.Compat ( Data/Aeson/Compat.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Compat.o ) [ 2 of 24] Compiling Data.Aeson.Internal.Functions ( Data/Aeson/Internal/Functions.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Internal/Functions.o ) [ 3 of 24] Compiling Data.Aeson.Parser.UnescapePure ( pure/Data/Aeson/Parser/UnescapePure.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Parser/UnescapePure.o ) [ 4 of 24] Compiling Data.Aeson.Parser.Unescape ( Data/Aeson/Parser/Unescape.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Parser/Unescape.o ) [ 5 of 24] Compiling Data.Aeson.Types.Generic ( Data/Aeson/Types/Generic.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Types/Generic.o ) [ 6 of 24] Compiling Data.Aeson.Types.Internal ( Data/Aeson/Types/Internal.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Types/Internal.o ) [ 7 of 24] Compiling Data.Aeson.Parser.Internal ( Data/Aeson/Parser/Internal.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Parser/Internal.o ) [ 8 of 24] Compiling Data.Aeson.Parser ( Data/Aeson/Parser.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Parser.o ) [ 9 of 24] Compiling Data.Attoparsec.Time.Internal ( attoparsec-iso8601/Data/Attoparsec/Time/Internal.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Attoparsec/Time/Internal.o ) [10 of 24] Compiling Data.Attoparsec.Time ( attoparsec-iso8601/Data/Attoparsec/Time.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Attoparsec/Time.o ) [11 of 24] Compiling Data.Aeson.Parser.Time ( Data/Aeson/Parser/Time.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Parser/Time.o ) [12 of 24] Compiling Data.Aeson.Types.FromJSON ( Data/Aeson/Types/FromJSON.hs, .stack-work/dist/i386-linux-nopie/Cabal-2.0.1.0/build/Data/Aeson/Types/FromJSON.o ) /tmp/stack15763/aeson-1.2.3.0/Data/Aeson/Types/FromJSON.hs:108:1: error: Bad interface file: /home/yotam/.stack/snapshots/i386-linux-nopie/lts-10.4/8.2.2/lib/i386-linux-ghc-8.2.2/time-locale-compat-0.1.1.3-EeYCrKbfyeWLGJYmfXhrGy/Data/Time/Locale/Compat.hi Data.Binary.getPrim: end of file | 108 | import Data.Time.Locale.Compat (defaultTimeLocale) | ^^ Is this a matter of just waiting for packages to update to 8.2.2 or is it something I can change myself? Yotam

4 4

Second Call for Papers: PACMPL issue ICFP 2018
by Lindsey Kuper 05 Feb '18

05 Feb '18

PACMPL Volume 2, Issue ICFP 2018 Call for Papers accepted papers to be invited for presentation at The 23rd ACM SIGPLAN International Conference on Functional Programming St. Louis, Missouri, USA http://icfp18.sigplan.org/ ### Important dates Submissions due: 16 March 2018 (Friday) Anywhere on Earth https://icfp18.hotcrp.com Author response: 2 May (Wednesday) - 4 May (Friday) 14:00 UTC Notification: 18 May (Friday) Final copy due: 22 June (Friday) Conference: 24 September (Monday) - 26 September (Wednesday) ### About PACMPL Proceedings of the ACM on Programming Languages (PACMPL <https://pacmpl.acm.org/>) is a Gold Open Access journal publishing research on all aspects of programming languages, from design to implementation and from mathematical formalisms to empirical studies. Each issue of the journal is devoted to a particular subject area within programming languages and will be announced through publicized Calls for Papers, like this one. ### Scope [PACMPL](https://pacmpl.acm.org/) issue ICFP 2018 seeks original papers on the art and science of functional programming. Submissions are invited on all topics from principles to practice, from foundations to features, and from abstraction to application. The scope includes all languages that encourage functional programming, including both purely applicative and imperative languages, as well as languages with objects, concurrency, or parallelism. Topics of interest include (but are not limited to): * *Language Design*: concurrency, parallelism, and distribution; modules; components and composition; metaprogramming; type systems; interoperability; domain-specific languages; and relations to imperative, object-oriented, or logic programming. * *Implementation*: abstract machines; virtual machines; interpretation; compilation; compile-time and run-time optimization; garbage collection and memory management; multi-threading; exploiting parallel hardware; interfaces to foreign functions, services, components, or low-level machine resources. * *Software-Development Techniques*: algorithms and data structures; design patterns; specification; verification; validation; proof assistants; debugging; testing; tracing; profiling. * *Foundations*: formal semantics; lambda calculus; rewriting; type theory; monads; continuations; control; state; effects; program verification; dependent types. * *Analysis and Transformation*: control-flow; data-flow; abstract interpretation; partial evaluation; program calculation. * *Applications*: symbolic computing; formal-methods tools; artificial intelligence; systems programming; distributed-systems and web programming; hardware design; databases; XML processing; scientific and numerical computing; graphical user interfaces; multimedia and 3D graphics programming; scripting; system administration; security. * *Education*: teaching introductory programming; parallel programming; mathematical proof; algebra. Submissions will be evaluated according to their relevance, correctness, significance, originality, and clarity. Each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant, and comparing it with previous work. The technical content should be accessible to a broad audience. PACMPL issue ICFP 2018 also welcomes submissions in two separate categories — Functional Pearls and Experience Reports — that must be marked as such at the time of submission and that need not report original research results. Detailed guidelines on both categories are given at the end of this call. Please contact the principal editor if you have questions or are concerned about the appropriateness of a topic. ### Preparation of submissions **Deadline**: The deadline for submissions is Friday, March 16, 2018, Anywhere on Earth (<https://en.wikipedia.org/wiki/Anywhere_on_Earth>). This deadline will be strictly enforced. **Formatting**: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from <https://www.acm.org/publications/authors/submissions>. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from <http://sigplan.org/Resources/Author/#acmart-format>. There is a limit of 27 pages for a full paper or 14 pages for an Experience Report; in either case, the bibliography will not be counted against these limits. These page limits have been chosen to allow essentially the same amount of content with the new single-column format as was possible with the two-column format used in past ICFP conferences. Submissions that exceed the page limits or, for other reasons, do not meet the requirements for formatting, will be summarily rejected. See also PACMPL's Information and Guidelines for Authors at <https://pacmpl.acm.org/authors.cfm>. **Submission**: Submissions will be accepted at <https://icfp18.hotcrp.com/> Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. **Author Response Period**: Authors will have a 72-hour period, starting at 14:00 UTC on Wednesday, May 2, 2018, to read reviews and respond to them. **Supplementary Materials**: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. The material should be uploaded at submission time, as a single pdf or a tarball, not via a URL. This supplementary material may or may not be anonymized; if not anonymized, it will only be revealed to reviewers after they have submitted their review of the paper and learned the identity of the author(s). **Authorship Policies**: All submissions are expected to comply with the ACM Policies for Authorship that are detailed at <https://www.acm.org/publications/authors/information-for-authors>. **Republication Policies**: Each submission must adhere to SIGPLAN's republication policy, as explained on the web at <http://www.sigplan.org/Resources/Policies/Republication>. **Resubmitted Papers**: Authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the principal editor will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. ### Review Process This section outlines the two-stage process with lightweight double-blind reviewing that will be used to select papers for PACMPL issue ICFP 2018. We anticipate that there will be a need to clarify and expand on this process, and we will maintain a list of frequently asked questions and answers on the conference website to address common concerns. **PACMPL issue ICFP 2018 will employ a two-stage review process.** The first stage in the review process will assess submitted papers using the criteria stated above and will allow for feedback and input on initial reviews through the author response period mentioned previously. At the review meeting, a set of papers will be conditionally accepted and all other papers will be rejected. Authors will be notified of these decisions on May 18, 2018. Authors of conditionally accepted papers will be provided with committee reviews (just as in previous conferences) along with a set of mandatory revisions. After five weeks (June 22, 2018), the authors will provide a second submission. The second and final reviewing phase assesses whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. The intent and expectation is that the mandatory revisions can be addressed within five weeks and hence that conditionally accepted papers will in general be accepted in the second phase. The second submission should clearly identify how the mandatory revisions were addressed. To that end, the second submission must be accompanied by a cover letter mapping each mandatory revision request to specific parts of the paper. The cover letter will facilitate a quick second review, allowing for confirmation of final acceptance within two weeks. Conversely, the absence of a cover letter will be grounds for the paper’s rejection. **PACMPL issue ICFP 2018 will employ a lightweight double-blind reviewing process.** To facilitate this, submitted papers must adhere to two rules: 1. **author names and institutions must be omitted**, and 2. **references to authors' own related work should be in the third person** (e.g., not "We build on our previous work ..." but rather "We build on the work of ..."). The purpose of this process is to help the reviewers come to an initial judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. ### Information for Authors of Accepted Papers * As a condition of acceptance, final versions of all papers must adhere to the new ACM Small format. The page limits for final versions of papers will be increased to ensure that authors have space to respond to reviewer comments and mandatory revisions. * Authors of accepted submissions will be required to agree to one of the three ACM licensing options: open access on payment of a fee (**recommended**, and SIGPLAN can cover the cost as described next); copyright transfer to ACM; or retaining copyright but granting ACM exclusive publication rights. Further information about ACM author rights is available from <http://authors.acm.org>. * PACMPL is a Gold Open Access journal. It will be archived in ACM’s Digital Library, but no membership or fee is required for access. Gold Open Access has been made possible by generous funding through ACM SIGPLAN, which will cover all open access costs in the event authors cannot. Authors who can cover the costs may do so by paying an Article Processing Charge (APC). PACMPL, SIGPLAN, and ACM Headquarters are committed to exploring routes to making Gold Open Access publication both affordable and sustainable. * ACM offers authors a range of copyright options, one of which is Creative Commons CC-BY publication; this is the option recommended by the PACMPL editorial board. A reasoned argument in favour of this option can be found in the article [Why CC-BY?](https://oaspa.org/why-cc-by/) published by OASPA, the Open Access Scholarly Publishers Association. * We intend that the papers will be freely available for download from the ACM Digital Library in perpetuity via the OpenTOC mechanism. * ACM Author-Izer is a unique service that enables ACM authors to generate and post links on either their home page or institutional repository for visitors to download the definitive version of their articles from the ACM Digital Library at no charge. Downloads through Author-Izer links are captured in official ACM statistics, improving the accuracy of usage and impact measurements. Consistently linking to the definitive version of an ACM article should reduce user confusion over article versioning. After an article has been published and assigned to the appropriate ACM Author Profile pages, authors should visit <http://www.acm.org/publications/acm-author-izer-service> to learn how to create links for free downloads from the ACM DL. * At least one author of each accepted submissions will be expected to attend and present their paper at the conference. The schedule for presentations will be determined and shared with authors after the full program has been selected. Presentations will be videotaped and released online if the presenter consents. * The official publication date is the date the papers are made available in the ACM Digital Library. This date may be up to *two weeks prior* to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. ### Artifact Evaluation Authors of papers that are conditionally accepted in the first phase of the review process will be encouraged (but not required) to submit supporting materials for Artifact Evaluation. These items will then be reviewed by an Artifact Evaluation Committee, separate from the paper Review Committee, whose task is to assess how the artifacts support the work described in the associated paper. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Authors of accepted papers will be encouraged to make the supporting materials publicly available upon publication of the papers, for example, by including them as "source materials" in the ACM Digital Library. An additional seal will mark papers whose artifacts are made available, as outlined in the ACM guidelines for artifact badging. Participation in Artifact Evaluation is voluntary and will not influence the final decision regarding paper acceptance. Further information about the motivations and expectations for Artifact Evaluation can be found at <https://icfp18.sigplan.org/track/icfp-2018-Artifacts>. ### Special categories of papers In addition to research papers, PACMPL issue ICFP solicits two kinds of papers that do not require original research contributions: Functional Pearls, which are full papers, and Experience Reports, which are limited to half the length of a full paper. Authors submitting such papers should consider the following guidelines. #### Functional Pearls A Functional Pearl is an elegant essay about something related to functional programming. Examples include, but are not limited to: * a new and thought-provoking way of looking at an old idea * an instructive example of program calculation or proof * a nifty presentation of an old or new data structure * an interesting application of functional programming techniques * a novel use or exposition of functional programming in the classroom While pearls often demonstrate an idea through the development of a short program, there is no requirement or expectation that they do so. Thus, they encompass the notions of theoretical and educational pearls. Functional Pearls are valued as highly and judged as rigorously as ordinary papers, but using somewhat different criteria. In particular, a pearl is not required to report original research, but, it should be concise, instructive, and entertaining. A pearl is likely to be rejected if its readers get bored, if the material gets too complicated, if too much specialized knowledge is needed, or if the writing is inelegant. The key to writing a good pearl is polishing. A submission that is intended to be treated as a pearl must be marked as such on the submission web page, and should contain the words "Functional Pearl" somewhere in its title or subtitle. These steps will alert reviewers to use the appropriate evaluation criteria. Pearls will be combined with ordinary papers, however, for the purpose of computing the conference's acceptance rate. #### Experience Reports The purpose of an Experience Report is to help create a body of published, refereed, citable evidence that functional programming really works — or to describe what obstacles prevent it from working. Possible topics for an Experience Report include, but are not limited to: * insights gained from real-world projects using functional programming * comparison of functional programming with conventional programming in the context of an industrial project or a university curriculum * project-management, business, or legal issues encountered when using functional programming in a real-world project * curricular issues encountered when using functional programming in education * real-world constraints that created special challenges for an implementation of a functional language or for functional programming in general An Experience Report is distinguished from a normal PACMPL issue ICFP paper by its title, by its length, and by the criteria used to evaluate it. * Both in the papers and in any citations, the title of each accepted Experience Report must begin with the words "Experience Report" followed by a colon. The acceptance rate for Experience Reports will be computed and reported separately from the rate for ordinary papers. * Experience Report submissions can be at most 12 pages long, excluding bibliography. * Each accepted Experience Report will be presented at the conference, but depending on the number of Experience Reports and regular papers accepted, authors of Experience reports may be asked to give shorter talks. * Because the purpose of Experience Reports is to enable our community to accumulate a body of evidence about the efficacy of functional programming, an acceptable Experience Report need not add to the body of knowledge of the functional-programming community by presenting novel results or conclusions. It is sufficient if the Report states a clear thesis and provides supporting evidence. The thesis must be relevant to ICFP, but it need not be novel. The review committee will accept or reject Experience Reports based on whether they judge the evidence to be convincing. Anecdotal evidence will be acceptable provided it is well argued and the author explains what efforts were made to gather as much evidence as possible. Typically, more convincing evidence is obtained from papers which show how functional programming was used than from papers which only say that functional programming was used. The most convincing evidence often includes comparisons of situations before and after the introduction or discontinuation of functional programming. Evidence drawn from a single person's experience may be sufficient, but more weight will be given to evidence drawn from the experience of groups of people. An Experience Report should be short and to the point: it should make a claim about how well functional programming worked on a particular project and why, and produce evidence to substantiate this claim. If functional programming worked in this case in the same ways it has worked for others, the paper need only summarize the results — the main part of the paper should discuss how well it worked and in what context. Most readers will not want to know all the details of the project and its implementation, but the paper should characterize the project and its context well enough so that readers can judge to what degree this experience is relevant to their own projects. The paper should take care to highlight any unusual aspects of the project. Specifics about the project are more valuable than generalities about functional programming; for example, it is more valuable to say that the team delivered its software a month ahead of schedule than it is to say that functional programming made the team more productive. If the paper not only describes experience but also presents new technical results, or if the experience refutes cherished beliefs of the functional-programming community, it may be better off submitted it as a full paper, which will be judged by the usual criteria of novelty, originality, and relevance. The principal editor will be happy to advise on any concerns about which category to submit to. ### ICFP Organizers General Chair: Robby Findler (Northwestern University, USA) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Ryan R. Newton (Indiana University, USA) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Matthew Fluet (Rochester Institute of Technology, USA) Publicity and Web Chair: Lindsey Kuper (Intel Labs, USA) Student Research Competition Chair: Ilya Sergey (University College London, UK) Video Co-Chairs: Jose Calderon (Galois, Inc., USA) Nicolas Wu (University of Bristol, UK) Workshops Co-Chair: David Christiansen (Indiana University, USA) Christophe Scholliers (Universiteit Gent, Belgium) ### PACMPL Volume 2, Issue ICFP 2018 Principal Editor: Matthew Flatt (Univesity of Utah, USA) Review Committee: Sandrine Blazy (IRISA, University of Rennes 1, France) David Christiansen (Indiana University, USA) Martin Elsman (University of Copenhagen, Denmark) Marco Gaboardi (University at Buffalo, CUNY, USA) Sam Lindley (University of Edinburgh, UK) Heather Miller (Northweastern University, USA / EPFL, Switzerland) J. Garrett Morris (University of Kansas, USA) Henrik Nilsson (University of Nottingham, UK) François Pottier (Inria, France) Alejandro Russo (Chalmers University of Technology, Sweden) Ilya Sergey (University College London, UK) Michael Sperber (Active Group GmbH, Germany) Wouter Swierstra (Utrecht University, UK) Éric Tanter (University of Chile, Chile) Katsuhiro Ueno (Tohoku University, Japan) Niki Vazou (University of Maryland, USA) Jeremy Yallop (University of Cambridge, UK) External Review Committee: Michael D. Adams (University of Utah, USA) Amal Ahmed (Northeastern University, USA) Nada Amin (University of Cambridge, USA) Zena Ariola (University of Oregon) Lars Bergstrom (Mozilla Research) Lars Birkedal (Aarhus University, Denmark) Edwin Brady ( University of St. Andrews, UK) William Byrd (University of Alabama at Birmingham, USA) Giuseppe Castagna (CRNS / University of Paris Diderot, France) Sheng Chen (University of Louisiana at Lafayette, USA) Koen Claessen (Chalmers University ot Technology, Sweden) Ugo Dal Lago (University of Bologna, Italy / Inria, France) David Darais (University of Vermont, USA) Joshua Dunfield (Queen’s University, Canada) Richard Eisenberg (Bryn Mawr College, USA) Matthew Fluet (Rochester Institute of Technology, USA) Nate Foster (Cornell University, USA) Jurriaan Hage (Utrecht University, Netherlands) David Van Horn (University of Maryland, USA) Zhenjiang Hu (National Institute of Informatics, Japan) Suresh Jagannathan (Purdue University, USA) Simon Peyton Jones (Microsoft Research, UK) Naoki Kobayashi (University of Tokyo, Japan) Neelakantan Krishnaswami (University of Cambridge, UK) Kazutaka Matsuda (Tohoku University, Japan) Trevor McDonell (University of New South Wales, Australia) Hernan Melgratti (University of Buenos Aires, Argentina) Akimasa Morihata (University of Tokyo, Japan) Aleksandar Nanevski (IMDEA Software Institute, Spain) Kim Nguyễn (University of Paris-Sud, France) Cosmin Oancea (DIKU, University of Copenhagen, Denmark) Bruno C. d. S. Oliveira (University of Hong Kong, China) Tomas Petricek (University of Cambridge, UK) Benjamin Pierce (University of Pennsylvania, USA) Christine Rizkallah (University of Pennsylvania, USA) Tom Schrijvers (KU Leuven, Belgium) Manuel Serrano (Inria, France) Jeremy Siek (Indiana University, USA) Josef Svenningsson (Chalmers University of Technology, Sweden) Nicolas Tabareau (Inria, France) Dimitrios Vytiniotis (Microsoft Research, UK) Philip Wadler (University of Edinburgh, UK) Meng Wang (University of Kent, UK)

1 0

Fwd: rolling span and groupBy for lists
by Harendra Kumar 05 Feb '18

05 Feb '18

Hi, I am looking for the decision making authority or a place where questions about haskell libraries like in the email below can be asked or answered. ghc-devs told me that their list is not the right place for this and redirected me to haskell-cafe or libraries(a)haskell.org. I tried sending an email to libraries(a)haskell.org but that seems to be a closed list, my email got rejected, so that also does not seem like the right place. Is haskell cafe the right place? I was under the impression that haskell-cafe is for general discussions and not an owner of any of the libraries or any other haskell code. Are there any other mailing lists that I am missing? I can raise a ticket at ghc trac but I guess that cannot be the primary way to ask simple questions. -harendra ---------- Forwarded message ---------- From: <libraries-owner(a)haskell.org> Date: 5 February 2018 at 09:34 Subject: Re: rolling span and groupBy for lists To: harendra.kumar(a)gmail.com You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at libraries-owner(a)haskell.org. ---------- Forwarded message ---------- From: Harendra Kumar <harendra.kumar(a)gmail.com> To: David Feuer <david(a)well-typed.com>, libraries <libraries(a)haskell.org> Cc: ghc-devs(a)haskell.org Bcc: Date: Mon, 5 Feb 2018 10:07:55 +0530 Subject: Re: rolling span and groupBy for lists I was mainly asking if it makes sense to include these functions in base/Data.List. Since the base package is maintained and ships along with ghc, and the issues are also raised at ghc trac I thought this is the right list. I am copying to libraries(a)haskell.org as well. -harendra On 5 February 2018 at 09:53, David Feuer <david(a)well-typed.com> wrote: > This is the wrong list. You probably meant to email haskell-cafe or > perhaps libraries(a)haskell.org. > > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Harendra Kumar <harendra.kumar(a)gmail.com> > Date: 2/4/18 10:50 PM (GMT-05:00) > To: ghc-devs(a)haskell.org > Subject: rolling span and groupBy for lists > > Hi, > > For a small problem, I was looking for a groupBy like function that groups > based on a predicate on successive elements but I could not find one. I > wrote these little functions for that purpose: > > -- | Like span, but with a predicate that compares two successive elements. > The > -- span ends when the two successive elements do not satisfy the predicate. > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) > rollingSpan _ xs@[] = (xs, xs) > rollingSpan _ xs@[_] = (xs, []) > rollingSpan p (x1:xs@(x2:_)) > | p x1 x2 = > let (ys, zs) = rollingSpan p xs > in (x1 : ys, zs) > | otherwise = ([x1], xs) > > -- | Like 'groupBy' but with a predicate that compares two successive > elements. > -- A group ends when two successive elements do not satisfy the predicate. > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] > rollingGroupBy _ [] = [] > rollingGroupBy cmp xs = > let (ys, zs) = rollingSpan cmp xs > in ys : rollingGroupBy cmp zs > > Are there any existing functions that serve this purpose or is there any > simpler way to achieve such functionality? If not, where is the right place > for these, if any. Can they be included in Data.List in base? > > Thanks, > Harendra >

2 2

Call for Participation: BOB 2018 (February 23, Berlin)
by Stefan Wehr 03 Feb '18

03 Feb '18

There are several Haskell-related talks and tutorials, see below for details! ================================================================ BOB 2018 Conference “What happens if we simply use what’s best?” February 23, 2018, Berlin http://bobkonf.de/2018/ Program: http://bobkonf.de/2018/en/program.html Registration: http://bobkonf.de/2018/en/registration.html ================================================================ BOB is the conference for developers, architects and decision-makers to explore technologies beyond the mainstream in software development, and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experiences. The program features 14 talks and 8 tutorials on current topics: http://bobkonf.de/2018/en/program.html The subject range of talks includes functional programming, verticalization, formal methods, and data analytics. There will be two talks about Haskell: * Testing monadic programs using QuickCheck and state machine based models * New Hasql - a native Haskell Postgres driver faster than C The tutorials feature introductions to Haskell, Clojure, Livecoding, terminal programming in Haskell, Liquid Haskell, functional reactive programming, and domain-driven design. Leif Andersen will give the keynote talk. Registration is open online: http://bobkonf.de/2018/en/registration.html BOB cooperates with the :clojured conference on the following day. There is a registration discount available for participants of both events. http://www.clojured.de/

1 0

MonadBaseControl and Freer
by Lana Black 02 Feb '18

02 Feb '18

Hello, I have a problem with implementing a MonadBaseControl instance for freer monad (Eff from extensible-effects). Specifically, I don't really get what the associated type StM should be. As far as I understand, MonadBaseControl class does the following: captures the current state. Performs the action passed to lifeBaseWith or other wrapper functions. Returns the result wrapped in the captured state. Here's the instance I could come up with. instance (MonadBase m (Eff r), Typeable m, SetMember Lift (Lift m) r) => MonadBaseControl m (Eff r) where type StM (Eff r) a = Eff r a liftBaseWith f = lift (f return) restoreM = id It obviously doesn't work, but I currently have no idea how to fix it, because `Eff r a' contains the state that needs to be captured and cannot be decomposed without losing data as far as I can see. The code can be found in this branch: https://github.com/greydot/extensible-effects/tree/monadbasecontrol As a side matter, I couldn't find any tests for MonadBaseControl instances, and monad-control package itself lacks any tests whatsoever. I'm curious whether there's a way to test instance correctness without plugging it into working code, e.g. something using lifted-base, and hoping for the best.

3 3

Spectre mitigations for Haskell
by Joey Hess 31 Jan '18

31 Jan '18

Has anyone thought about the impact of the Spectre attack (https://spectreattack.com/spectre.pdf) on Haskell programs, and mitigations? Here's my initial thoughts, bearing in mind that low level stuff is not my forte.. There are likely to be many gadgets in the ghc RTS that could be used by a Spectre variant 2 attack, using indirect branch poisoning. Since the RTS is mostly C code, C compiler mitigations such as retpoline can avoid the indirect branch prediction problems. There's also assembly in the RTS. For example, StgCRun.c contains a "jmp eax" indirect branch which might be vulnerable. FFI code can also contain vulnerable indirect branches both C and assembly. It would be good if at least securemem wasn't vulnerable to Spectre variant 2, so that Haskell programs operating on very private data could use it to avoid the attack. But, even if securemem itself doesn't contain any vulnerable gadgets (its constant time Eq shouldn't branch, which helps..), other vulnerable gadgets in the RTS and elsewhere can still be pointed at the securemem buffer. I do have Haskell programs that I would like to harden against Spectre variant 2, since they're sometimes used in a multi-user environment and operate on private data. As for Spectre variant 1, it would need something like a haskell implementation of a javascript interpreter running untrusted code, or something like lambdabot running safe haskell code. That would then be vulnerable to conditional branch misprediction to expose whatever private data the process has access to. Perhaps a sufficiently smart compiler could do something about Spectre variant 1, but there are probably not too many vulnetable programs and it can be prevented in the program by eg avoiding exposure of high-resolution timers, the same way web browsers have been dealing with this attack. -- see shy jo

1 0

addFinalizer in GHC 7.10
by Kazu Yamamoto 31 Jan '18

31 Jan '18

Hello cafe, We, the network library maintainers, have questions about System.Mem.Weak.addFinalizer in GHC 7.10. We are trying to make the library extensible especially for the socket type and the socket address type. For this purpose, a proposed definition for Socket in version 3.0.0.0 is a just CInt: newtype Socket = Socket CInt deriving (Eq, Show) One problem is that unreachable Socket cannot be GCed if CInt (a file descriptor) is not closed. To let GC work, we are trying to add a finalizer via addFinalizer: socket family stype protocol = do fd <- c_socket ... ... let s = Socket fd addFinalizer s $ close s ruturn s This works well for many cases. Unfortunately, we *sometime* got the following error with GHC 7.10: tests/SimpleSpec.hs:56: 1) Simple.sendMany works well uncaught exception: IOException of type InvalidArgument (threadWait: invalid argument (Bad file descriptor)) It seems to us that Socket is GCed too early in GHC 7.10. We don't see this behavior in other versions of GHC. So, here are our questions: Q1) Do we use addFinalizer correctly? Q2) Is this a bug of GHC 7.10? Q3) If this is a bug of GHC 7.10, are there any workarounds? --Kazu

3 6

BayHac 2018 announcement
by Dan Burton 30 Jan '18

30 Jan '18

I am pleased to announce that BayHac 2018 will be held at the Takt office in San Francisco on the weekend of Friday, April 27 thru Sunday, April 29. BayHac is a Haskell hackathon weekend event for the San Francisco Bay Area and Silicon Valley. It will be a weekend of learning, hacking, and connecting with fellow Haskell enthusiasts. See the page for BayHac 2018 on the haskell.org wiki for details: https://wiki.haskell.org/BayHac2018 -- Dan Burton

1 0

What's the story behind "applicative" in "Constant Applicative Form"?
by sonne 29 Jan '18

29 Jan '18

Hi cafe. I've been trying to make the concept of CAFs get through to me, but the very name is cryptic enough to stupefy me. What does it mean for a thing to be "applicative"? Is it related to the concept of applicative functor (likely not)? What would a constant non-applicative form look like? A non-constant applicative form? An applicative non-form, in the end? I put a question on Stack Overflow about this, only to discover no one's really sure. I would appreciate either an answer put there right away or a permission to re-post or rephrase an answer there myself, but, if you do mind, I will of course keep the answer private to this mailing list. This is the link to the question: stackoverflow.com/questions/48489778 Thank you! P.S. I guess this is my first e-mail to this list, so please kindly let me know if it's unfit or in any way out of line.

2 1

Taking over maintainership of exact-pi
by Andrew Lelechenko 27 Jan '18

27 Jan '18

I would like to take over `exact-pi` package (https://hackage.haskell.org/package/exact-pi) Unfortunately, the package became incompatible with upcoming GHC 8.4 and needs an upgrade. The relevant pull request (https://github.com/dmcclean/exact-pi/pull/5) prepared by @konn, has been open for a month without response. I also tried to reach its maintainer Douglas McClean (cced) by email, but have not heard back. I am so interested in upgrading `exact-pi`, because it is a dependency of my package `arithmoi`. — Best regards, Andrew

3 2

LTS-10.* missing build-depends suggestion
by Rick Owens 25 Jan '18

25 Jan '18

Dear Haskell Café, I am a long-time Haskell developer with a proliferation of private projects. I typically make very heavy use of stack and LTS. Today, I tried to bootstrap my first project using LTS-10.* (with GHC-8.2.2) and I ran into an interesting problem (for me). In the past, with lts-9.* and below, when I started cranking on some code and writing a bunch of imports: > import Control.Monad.Trans.Class (MonadTrans) > import Data.Map (Map) I would try to build first without updating the cabal file build-depends, and I would get something like the following error messages: > /path/to/Module.hs:48:1: error: > Failed to load interface for ‘Data.Map’ > It is a member of the hidden package ‘containers-0.5.7.1’. > Perhaps you need to add ‘containers’ to the build-depends in your .cabal file. > Use -v to see a list of the files searched for. > > /path/to/Module.hs:21:1: error: > Failed to load interface for ‘Control.Monad.Trans.Class’ > It is a member of the hidden package ‘transformers-0.5.2.0’. > Perhaps you need to add ‘transformers’ to the build-depends in your .cabal file. > Use -v to see a list of the files searched for. This was good because the error contained a suggested solution which contained the missing package, and I could sort of lazily add the build-depends I needed without having to memorize a (Module -> Package) mapping. I even had developer tooling to do it automatically. With lts-10.*, however, the analogous error message looks like this: > /path/to/Module.hs:9:1: error: > Could not find module ‘Data.DoubleWord’ > Use -v to see a list of the files searched for. > | > 9 | import Data.DoubleWord (Word256(Word256), Word128(Word128)) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I am wondering, is there a way to bring back the solution suggestion? Not having access to it has made me realize how heavily I was using that feature. What do others think about this missing bit of supplemental error information? Thanks, -Rick Owens

3 6

Multiple positions open
by Lee Pike 25 Jan '18

25 Jan '18

We have multiple positions open doing work at the intersection of Haskell, compilers, and machine learning, as well as Haskell-based infrastructure (CI, builds, etc.) Preferably Portland, Oregon or Palo Alto, California. Email me for details! Lee

1 0

Caching Actions
by Yotam Ohad 25 Jan '18

25 Jan '18

Hi, I've been digging around the source code of reactive-banana and I found this code <https://github.com/HeinrichApfelmus/reactive-banana/blob/master/reactive-ba…>: data Cached m a = Cached (m a) runCached :: Cached m a -> m a runCached (Cached x) = x -- | An action whose result will be cached. -- Executing the action the first time in the monad will -- execute the side effects. From then on, -- only the generated value will be returned. {-# NOINLINE cache #-} cache :: (MonadFix m, MonadIO m) => m a -> Cached m a cache m = unsafePerformIO $ do key <- liftIO $ newIORef Nothing return $ Cached $ do ma <- liftIO $ readIORef key -- read the cached result case ma of Just a -> return a -- return the cached result. Nothing -> mdo liftIO $ -- write the result already writeIORef key (Just a) a <- m -- evaluate return a I'm trying to understand the reasom behind the use of mdo. Can't it be like this: do a <- m liftIO $ writeIORef key (Just a) return a Removing the need for a recursive definition? Yotam

3 2

Munich Haskell Meeting, 2018-01-29 @ 19:30
by Christian Neukirchen 25 Jan '18

25 Jan '18

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, January 29 at **Cafe Puck** at 19h30. For details see here: http://muenchen.haskell.bayern/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-jan-2018/ [Please note: I'll likely arrive 8-9pm this time since I need to wait for my water meter to get changed. I'll book for Neukirchen as usual.] Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

Large JSON File Processing
by erik 25 Jan '18

25 Jan '18

Hello Haskell Cafe, I have written a small, pretty simple program but I am finding it hard to reason about its behavior (and also about the best way to do what I want), so I would like to ask you all for some suggestions. For reference, here's a Stack Overflow question <https://stackoverflow.com/questions/48330690/haskell-conduit-aeson-parsing-…> where I described what's going on, but I'll also describe it below. My program does the following: 1. Recursively list a directory, 2. Parse the JSON files from the directory list into identifiable objects/records, 3. Look for matching key-value pairs, and 4. Return filenames where matches have been found. A few details for more context: - I have to filter between 500,000 and 1 million files (I'm typically trying to reduce down to between 1,000 and 40,000 that represent a particular project). I usually just need the filenames. - Each file is quite large, some of them 5mb or 10mb, and it's not uncommon for them to have deeply nested keys (40,000 keys or so). My first version of this program was simple, synchronous, and as straightforward as I could come up with. However, the memory usage increased monotonically. Profiling, I found that most of the time was spent in JSON-parsing into Objects before my code could turn the objects into records (also, as you might imagine, tons of time in garbage collection). For my second version, I switched to conduit and it seemed to solve the increasing memory issue. My core function now looked like this: conduitFilesFilter :: ProjectFilter -> Path Abs Dir -> IO [Path Abs File] conduitFilesFilter projFilter dirname' = do (_, allFiles) <- listDirRecur dirname' C.runConduit $ C.yieldMany allFiles .| C.filterMC (filterMatchingFile projFilter) .| C.sinkList This was still slow and certainly still synchronous. What I really wanted was to run that "filterMatchingFile..." part in parallel across a number of CPUs. As an aside, my filtering function looks like this: filterMatchingFile :: ProjectFilter -> Path Abs File -> IO Bool filterMatchingFile (ProjectFilter filterFunc) fpath = do let fp = toFilePath fpath bs <- B.readFile fp case validImplProject bs of -- this is pretty much just `decodeStrict` Nothing -> pure False (Just proj') -> pure $ filterFunc proj' Here are the stats from running this: 115,961,554,600 bytes allocated in the heap 35,870,639,768 bytes copied during GC 56,467,720 bytes maximum residency (681 sample(s)) 1,283,008 bytes maximum slop 145 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 108716 colls, 108716 par 76.915s 20.571s 0.0002s 0.0266s Gen 1 681 colls, 680 par 0.530s 0.147s 0.0002s 0.0009s Parallel GC work balance: 14.99% (serial 0%, perfect 100%) TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.007s elapsed) MUT time 34.813s ( 42.938s elapsed) GC time 77.445s ( 20.718s elapsed) EXIT time 0.000s ( 0.010s elapsed) Total time 112.260s ( 63.672s elapsed) Alloc rate 3,330,960,996 bytes per MUT second Productivity 31.0% of total user, 67.5% of total elapsed gc_alloc_block_sync: 188614 whitehole_spin: 0 gen[0].sync: 33 gen[1].sync: 811204 I thought about writing a plainer (non-conduit) parallel version but I was afraid of the memory issue. I tried to write a Conduit-plus-channels version but it didn't work. Finally, I wrote a version using stm-conduit, which I thought might be a bit more efficient. It seems to be slightly better, but it's not really the kind of parallelization I was imagining: conduitAsyncFilterFiles :: ProjectFilter -> Path Abs Dir -> IO [String] conduitAsyncFilterFiles projFilter dirname' = do (_, allFiles) <- listDirRecur dirname' buffer 10 (C.yieldMany allFiles .| (C.mapMC (readFileWithPath . toFilePath))) (C.mapC (filterProjForFilename projFilter) .| C.filterC isJust .| C.mapC fromJust .| C.sinkList) The first conduit passed to `buffer` does something like the following: parseStrict . B.readFile. This still wasn't too great, but after reading about handing garbage collection in smarter ways, I found that I could run my application like this: stack exec search-json -- --searchPath $FILES --name hello +RTS -s -A32m -n4m And the "productivity" would shoot up quite a lot presumably because I'm doing less frequent garbage collection. My program also got a bit faster: 36,379,265,096 bytes allocated in the heap 1,238,438,160 bytes copied during GC 22,996,264 bytes maximum residency (85 sample(s)) 3,834,152 bytes maximum slop 207 MB total memory in use (14 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 211 colls, 211 par 1.433s 0.393s 0.0019s 0.0077s Gen 1 85 colls, 84 par 0.927s 0.256s 0.0030s 0.0067s Parallel GC work balance: 67.93% (serial 0%, perfect 100%) TASKS: 10 (1 bound, 9 peak workers (9 total), using -N4) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.004s elapsed) MUT time 12.636s ( 12.697s elapsed) GC time 2.359s ( 0.650s elapsed) EXIT time -0.015s ( 0.003s elapsed) Total time 14.982s ( 13.354s elapsed) Alloc rate 2,878,972,840 bytes per MUT second Productivity 84.2% of total user, 95.1% of total elapsed gc_alloc_block_sync: 9612 whitehole_spin: 0 gen[0].sync: 2044 gen[1].sync: 47704 Thanks for reading thus far. I now have three questions. 1. I understand that my program necessarily creates tons of garbage because it parses and then throws away 5mb of JSON 500,000 times. However, I don't really understand why this helps "+RTS -A32m -n4m" and I'm always reluctant to sprinkle in magic I don't fully understand. Can anyone help me understand what this means? 2. It seems that the allocation limit is really something I should be using, but I can't figure out how to successfully add it to my package.yml with the other options. From the documentation for GHC 8.2, I thought it needed to look like this but it never works, usually telling me that -A32m and -n4m are not recognizable flags (how do I add them in to my package.yml so I don't have to pass them when running the program?): ghc-options: - -threaded - -rtsopts - "-with-rtsopts=-N4 -A32m -n4m" 3. Finally, the most important question I have is this. When I run this program on OSX, it runs successfully through to completion. However, *a few minutes after terminating*, my terminal becomes unresponsive. I use emacs for my editor, typically launched from a terminal window and that too becomes unresponsive. This is not a typical outcome for any programs I write and it happens *every time* I run this particular application, so I know that this application is to blame. The crazy thing is that force quitting the terminal or logging out doesn't help: I have to actually restart my computer to use the terminal application again. Other details that may help: - This crash happens after the process id for my program has terminated. - Watching its progress in HTOP, it never comes close to running out of memory: the value hovers in the same place. I can't really deploy an application that has this potential-crashing problem, but I don't know to debug this issue. My total stab-in-the-dark idea is that heap allocations somehow are unrecoverable even after the process has terminated? Can anyone offer suggestions on things to look for or ways to debug and/or fix this issue? Finally, if anyone has suggestions on better ways to structure my application or parallelize the slow parts, I'll happily take those. Thanks again for reading. I appreciate any suggestions you may have. Best, -- Erik Aker

2 5

I really don't understand this
by Jean-Marc Alliot 24 Jan '18

24 Jan '18

I apologize if my question is stupid, but here is a simple Haskell program which never stops. However, if I comment the line (which is apparently useless): v<-acc The program works like a charm... I am using GHC 8.0.2 (debian sid) and multiset 0.3.3. If anyone has an idea, I would gladly hear it. Thanks in advance PS: don't try to understand what the program is doing; it is just the reduction to a few lines of a much larger code; I have tried to find a smaller subset which is not working "properly". PPS: The program can also be downloaded from: http://www.alliot.fr/tmp/example.hs import qualified Data.IntMultiSet as IMS b :: IMS.IntMultiSet b = IMS.fromList ([1, 2, 3, 4]) search :: IMS.IntMultiSet -> Int -> IO Bool search mynumbers nb = ins mynumbers (return False) where ins numbers acc = do v <- acc IMS.fold (\x acc1 -> let numbers2 = IMS.delete x numbers in IMS.fold (\y acc2 -> let numbers3 = IMS.delete y numbers2 res = x + y in if res == nb then (return True) else ins (IMS.insert res numbers3) acc2) acc1 numbers2) acc numbers main = do v <- search b 999999999 print v

2 5

Coding Haskell in a music start-up?
by Bas de Haas 24 Jan '18

24 Jan '18

Dear Haskellers, Chordify is hiring! Chordify is a young and fast growing music e-learning platform that helps musicians to play their favorite music. We automatically analyse the chords of a piece of music and display them in an intuitive player. Try it yourself at: https://chordify.net/ or download one of our apps https://chordify.net/app The cool thing is: our backend serving our apps and website has been written almost exclusively in Haskell. We hope to broaden our team with a functional programmer and a front-end developer. We are looking for people who are pro-active, independent, and creative to improve Chordify. You’d work in a small team of dedicated people with various backgrounds in which you can make a difference. If you are interested in working at Chordify, you can find the details here: https://chordify.homerun.co/ All the best, Bas de Haas

1 0

SLURP: a single unified registry for Haskell packages
by Simon Peyton Jones 24 Jan '18

24 Jan '18

Friends Hackage has been extraordinarily successful as a single repository through which to share Haskell packages. It has supported the emergence of variety of tools to locate Haskell packages, build them and install them (cabal-install, Stack, Nix, ...). But in recent years there has been increasing friction over, * Hackage's policies, especially concerning version bounds; * Hackage's guarantees, especially around durability of package content and metadata; * Hackage's features, especially the visual presentation and package documentation. If we do not resolve this friction, it seems likely that the Haskell library ecosystem will soon "fork", with two separate repositories, one optimised for Cabal and one for Stack. This would be extremely counter-productive for Haskell users. Thus motivated, over the last few months we have talked a lot to colleagues, including ones in the Hackage and Stack communities. We have emerged with SLURP, a proposal that could go a long way towards supporting the upsides of a diverse ecosystem, without the sad downsides of forking into mutually-exclusive sub-communities. Here is the SLURP proposal<https://github.com/simonmar/ecosystem-proposals/blob/slurp/proposals/0000-s…>. We invite the Haskell community to debate it. SLURP is meant to enable both Hackage and Stackage (and perhaps more services in the future) to in the future make choices autonomously without hurting other package services. But it will only work if the implementors of both Hackage and Stackage are willing to participate. We respect their autonomy in this matter, but we urge them to give this proposal serious consideration in the best interests of the community and Haskell's success. We have carefully designed SLURP to be as minimal and non-invasive as possible, so that it can be adopted without much trouble. Of course, we are open to debate about the specific details. We do have an offer from someone willing to implement SLURP. We also strongly urge members of the community to express clear views about the importance --- or otherwise --- of adopting something like SLURP. You are, after all, the community that GHC, Hackage, Stackage, Cabal, etc are designed to serve, so your views about what best meets your needs are critically important. Mathieu Boespflug (@mboes<https://github.com/boes>) Manuel Chakravarty (@mchakravarty<https://github.com/mchakravarty>) Simon Marlow (@simonmar<https://github.com/simonmar>) Simon Peyton Jones (@simonpj<https://github.com/simonpj>) Alan Zimmerman (@alanz<https://github.com/alanz>)

4 3

ANN: containers-0.5.11.0
by David Feuer 23 Jan '18

23 Jan '18

We have just released containers version 0.5.11.0. This is the first release since Matt Renaud joined the maintenance team. Matt has focused on documentation, code quality, and testing, and made some substantial contributions in these areas. This release comes with quite a few new functions and instances, written by quite a few different contributors. It also includes a complete overhaul of the sorting machinery in Data.Sequence thanks to Donnacha Oisín Kidney. And Matt Renaud has launched a brand new set of tutorial documentation at https://haskell-containers.readthedocs.io/en/latest/ Many thanks to all the contributors who made this release possible! The complete changelog can be found below. David Feuer Matt Renaud Wren Romano New functions and class instances * Add a `MonadFix` instance for `Data.Sequence`. * Add a `MonadFix` instance for `Data.Tree`. * Add `powerSet`, `cartesianProduct`, and `disjointUnion` for `Data.Set`. (Thanks, Edward Kmett.) * Add `disjoint` for `Data.Set` and `Data.IntSet`. (Thanks, Víctor López Juan.) * Add `lookupMin` and `lookupMax` to `Data.IntMap`. (Thanks, bwroga.) * Add `unzip` and `unzipWith` to `Data.Sequence`. Make unzipping build its results in lockstep to avoid certain space leaks. * Add carefully optimized implementations of `sortOn` and `unstableSortOn` to `Data.Sequence`. (Thanks, Donnacha Oisín Kidney.) Changes to existing functions and features * Make `Data.Sequence.replicateM` a synonym for `replicateA` for post-AMP `base`. * Rewrite the `IsString` instance head for sequences, improving compatibility with the list instance and also improving type inference. We used to have instance IsString (Seq Char) Now we commit more eagerly with instance a ~ Char => IsString (Seq a) * Make `>>=` for `Data.Tree` strict in the result of its second argument; being too lazy here is almost useless, and violates one of the monad identity laws. Specifically, `return () >>= \_ -> undefined` should always be `undefined`, but this was not the case. * Harmonize laziness details for `minView` and `maxView` between `Data.IntMap` and `Data.Map`. Performance improvement * Speed up both stable and unstable sorting for `Data.Sequence` (Thanks, Donnacha Oisín Kidney.) Other changes * Update for recent and upcoming GHC and Cabal versions (Thanks, Herbert Valerio Reidel, Simon Jakobi, and Ryan Scott.) * Improve external and internal documentation (Thanks, Oleg Grenrus and Benjamin Hodgson.) * Add tutorial-style documentation. * Add Haddock `@since` annotations for changes made since version 0.5.4 (Thanks, Simon Jakobi.) * Add a (very incomplete) test suite for `Data.Tree`. * Add structural validity checks to the test suites for `Data.IntMap` and `Data.IntSet` (Thanks to Joachim Breitner for catching an error in a first draft.)

2 1

[ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 21 Jan '18

21 Jan '18

The GHC development team is pleased to announce the first alpha release of the 8.4.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha1 Note that this release drops compatibility with GCC 4.6 and earlier. While we generally try to place as few constraints on system toolchain as possible, this release depends upon the __atomic__ builtins provided by GCC 4.7 and later (see #14244). === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceeded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes in to users hands and allow better feedback on the status of the release. GHC 8.4 is slated to be released in mid-February but, due to technical constraints, we are starting the alpha-release cycle a bit later than planned under the above schedule. For this reason, it would be greatly appreciated if users could put this alpha through its paces to make up for lost time. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

3 4

FRP: Why is Behavior not a Monad?
by martin 20 Jan '18

20 Jan '18

Hello all, it appears to be difficult to define a Monad instance for Behavior and in many (if not all) reactive libraries Behavior is not a Monad. Why is that so? If a Beahvior is conceptionally a function from Time to something, newtype Behavior a = Behavior (Time -> a) then its Monad instance should work like a Reader Monad. Alternatively one can look at the join function join :: Behavior (Behavior a) -> Behavior a. This corresponds to the situation where you switch between Channels on a TV remote controle and each Channel is a behavior of Image. Then join Behavior (Behavior image) should give you the video stream you see on the screen. How can one possibly live without this operation? I assume this has something to do with the actual implementation and not so much with the semantics, because semantically I don't see any problems. So, - why is Behavior not a Monad and - how would you express the TV-remote example without a Monad?

4 3

How to use FRP for Simulation
by martin 20 Jan '18

20 Jan '18

Hello all, the answer to the question "what is FRP good for?" often includes "simulation". I somewhat understand the "reactive" situation, where an FRP system receives Events from the outside world and computes Events to be sent to the outside world. To do so, the computation uses Behaviors which are essentially time-varying states. I also read, that the programmer should not be allowed to literally define Events and Behaviors, or she might end up writing bad prograns which exhibit time or space leaks. She should only be allowed to define transformations. Now in a discrete event simulation (DES) there is a lot of "event stuff" going on and FRP looks like a good paradigm. However, in a simulation nothing comes from the outside world and not much goes to the outside world. There is a simulation result, but it is just a result like any other and doesn't have much to do with Time. A DES is not really a reactive system at all. In DES there is typically a set of initial Events and more events are created as the simulation progresses. I cannot see how this can be done without the power to explicitly create Events. Also these Events point to the "future" and must therefore carry an explicit (simulated) Time, whereas (IIRC) in FRP, Events do not necessarily carry an explicit Time. They just occur, and if you need the time, you look at the clock (a Behavior Time). So what exactly is meant by "FRP is useful for simulation". Does it mean that a DES engine can be written in FRP style or does it mean something else? If one can indeed write a DES engine in FPR style, what is the correct way of thinking about it?

1 0

FRP: how does integration work?
by martin 20 Jan '18

20 Jan '18

Hello all, I am at best half-educated when it comes to FRP, so feel free to direct me to the homework I should do before asking obvious questions. I vaguely remember Paul Hudak talking about integrating a Signal (aka Behavior). Now I have this image in my head, where a Behavior is like vector graphics, except its domain Time and not space. Also I heard the term "late sampling" in conjunction with FRP. Bot ideas make sense to me. So if I look at integration in vector graphics, I might want to get the area between a curve and the x-axis. If I render the curve and then count the pixels between the curve and x-axis, the result will depend on the resolution. With a very low resolution, I'll get a crude approximation of the true area and as I increase the resolution I'll get better approximations and with infinite resolution I'll get the true area. So the result of integration seems to depend on the chosen resolution. Conversely, with pixel graphics, the resolution is fixed right from the start and I cannot not up the resolution at all, at best I could downsample. In FRP I should have something like: newtype Behavior a = Behavior (Time -> a) type Curve = Behavior Double integral :: Curve -> Double -> Curve -- 2nd parameter is the integration constant But what do I get when I take the value of the integral at a given point in time? integralAt :: Time -> Curve -> Double integralAt t curve = let (Behaviour i) = integral curve 0 in i t Nowhere do I mention any (temporal) resolution. How does the integral function know which resoltion to choose?

1 0

Adding packages from within ghci session
by Simon Hafner 20 Jan '18

20 Jan '18

Hello I've been exploring some code via ghci, and I've found myself in this loop: - write some code - figure out I need another package (e.g. mtl for runReaderT) - add package to cabal specification - reload stack ghci - Ctrl+R all the statements to replay the session so far Is there a way to speed up the loop, e.g. via loading packages directly from ghci or saving/replaying a session? Cheers, Simon

3 3

Created haskell-indexer-users mailing list
by Robin Palotai 19 Jan '18

19 Jan '18

Hello Cafe, I created https://groups.google.com/forum/#!forum/haskell-indexer-users, please join if you use / interested in using haskell-indexer [1]! Quoting Section 4.5.5 of the latest HCAR [2], > > Haskell Indexer is a Kythe extension for working with Haskell source code. > Kythe is language-agnostic ecosystem for building tools that work with > code. An example is code search with cross-reference support: > https://cs.chromium.org/. Haskell Indexer makes it possible to use > Kythe-based tools with Haskell. With Haskell Indexer it’s possible to list > all use-sites of any given function (get reverse-references) and explore > the code without any IDE setup. > A portion of GHC and Stackage is indexed and available at > http://stuff.codereview.me/. Thank you & happy coding, Robin [1] https://github.com/google/haskell-indexer [2] https://www.haskell.org/communities/11-2017/html/report.html

1 0