May 2020 - Haskell-Cafe

stack: pandoc fails to build as dependency
by Olaf Klinke 06 Aug '20

06 Aug '20

Dear cafe, I am baffled to learn that stack does not provide builds as reproducible as advertised. I have a project that depends on pandoc. It builds fine on my Debian 9 machine. Then I check out the project on a Debian 8 machine. Downloading and building pandoc-2.7.3 with the latest stack-2.1.3 on the Debian 8 machine runs fine. Now I create a new project, using the same stack.yaml as in the pandoc-2.7.3 package, except now pandoc-2.7.3 is an extra-dep. The project's only module contains nothing but: module Test where import Text.Pandoc Building this project with the same stack results in a linker error: pandoc > Preprocessing executable 'pandoc' for pandoc-2.7.3.. pandoc > Building executable 'pandoc' for pandoc-2.7.3.. pandoc > [1 of 2] Compiling Main pandoc > [2 of 2] Compiling Paths_pandoc pandoc > Linking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/pandoc/pandoc ... pandoc > collect2: error: ld returned 1 exit status pandoc > `gcc' failed in phase `Linker'. (Exit code: 1) This seems to be independent of the LTS version (the stack.yaml in pandoc-2.7.3 says lts-13.17 although lts-13.17 contains pandoc-2.5 and pandoc-2.7.3 is available only in 14.9). Can somebody hint what I am doing wrong? Should I file a bug report? Thanks Olaf

3 3

[HIW'20] Second Call for Talks
by Ben Gamari 24 Jun '20

24 Jun '20

Hello everyone, Haskell Implementors Workshop is calling for talk proposals. Co-located with ICFP, HiW is an ideal place to describe a Haskell library, a Haskell extension, compiler, works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. The deadline for submissions is July 2nd 2020. Call for Talks ============== The 12th Haskell Implementors’ Workshop is to be held alongside ICFP 2020 this year. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos and lightning talks. Scope and Target Audience ------------------------- It is important to distinguish the Haskell Implementors’ Workshop from the Haskell Symposium which is also co-located with ICFP 2020. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors’ Workshop will have no proceedings – although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop – we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: - Compilation techniques - Language features and extensions - Type system implementation - Concurrency and parallelism: language design and implementation - Performance, optimization and benchmarking - Virtual machines and run-time systems - Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions can be made via HotCRP at https://icfp-hiw20.hotcrp.com/ until July 2nd (anywhere on earth). We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- - Andrey Mokhov (Newcastle University) - Ben Gamari (Well-Typed LLP) - Christian Baaij (QBayLogic) - George Karachalias (Tweag I/O) - Klara Marntirosian (KU Leuven) - Matthew Pickering (Univeristy of Bristol) - Ryan G.L. Scott (Indiana University Bloomington) Best wishes, ~ Ben

1 1

Why does Haskell have both `Maybe a` and `Either a ()`?
by Wiebe-Marten Wijnja 30 May '20

30 May '20

Greetings, everyone! Recently I was involved in a discussion on the new ML-style language 'gleam'. Gleam has for quite a while now only had an `Either a b` type, with all functions that in Haskell one would use a `Maybe a` for, working on an `Either a ()` instead. In the discussion(https://github.com/gleam-lang/gleam/issues/591), the language designers were asking the community whether it would make sense to add `Maybe` to the language as well, or keep using only `Either a ()`. My question: Is the difference between `Maybe a` and `Either a ()` only semantic and are they functionally equivalent, or are there differences in functionality as well? Have a nice day, ~Marten / Qqwy

8 7

ANN: Data.Monoid.First and Data.Monoid.Last are here to stay
by Simon Jakobi 29 May '20

29 May '20

Hi! I'm happy to report that the planned deprecation of Data.Monoid.{First,Last} [0] has finally been scrapped [1]. The original motivation for removing these newtypes of Maybe was to resolve the name conflict with Data.Semigroup.{First,Last} [2]. Unfortunately, while implementing the deprecation, I ended up discovering a whole host of problems with the suggested migration to (Maybe Data.Semigroup.First) and (Maybe Data.Semigroup.Last), which I have attempted to summarize in my email to the libraries mailing list [3]. I would like to thank everyone who contributed to the discussion of the matter, the CLC, and also everyone who pushed me to finally get the matter resolved. :) Cheers! Simon [0] http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Monoid.html#t:Fi… [1] https://gitlab.haskell.org/ghc/ghc/-/commit/f44d7ae08442ae6227db37cacc97fe0… [2] https://mail.haskell.org/pipermail/libraries/2018-April/028712.html [3] https://mail.haskell.org/pipermail/libraries/2020-April/030357.html

1 0

[Open Kattis Problem] How can I speed up my A* algorithm and/or binomial heaps?
by Dominik Bollmann 24 May '20

24 May '20

Hi Haskell-Cafe, I've been trying to solve the Problem "10 Kinds Of People" at https://open.kattis.com/problems/10kindsofpeople. My idea was to use the A* algorithm to check whether the destination can be reached from the source. To model the A* algorithm's priority queue, I also wrote a naive implementation of a binomial heap. I've attached the code snippet below. Unfortunately, my solution doesn't pass all of Open Kattis' test cases. In particular, it times out on the 22nd test case. Therefore I'm wondering how to speed up my solution. Did I make any obvious, silly mistakes? According to my time-profiling it seems that most of the time is spent in the binomial heap's deleteMin function. Maybe I should therefore not model the Heap as a list of trees, but rather as a vector of trees? Any hints on how to make the below snippet run faster is highly appreciated! :-) Thanks! Dominik ============================================= import Control.Monad import Data.Function import Data.Foldable (foldl') import Data.List (minimumBy, delete) import Data.Maybe import qualified Data.Set as S import qualified Data.Vector as V data Tree a = Node Int a [Tree a] deriving (Eq, Show) type Heap a = [Tree a] rank :: Tree a -> Int rank (Node k _ _) = k root :: Tree a -> a root (Node _ x _) = x children :: Tree a -> [Tree a] children (Node _ _ cs) = cs findMin :: Ord a => Heap a -> Maybe a findMin [] = Nothing findMin (t:ts) = Just . root $ foldl' selectMin t ts where selectMin e a | root e <= root a = e | otherwise = a empty :: Heap a empty = [] singleton :: Ord a => a -> Heap a singleton x = insert x empty insert :: Ord a => a -> Heap a -> Heap a insert x ts = foldr increment singleton ts where singleton = [Node 0 x []] increment t (h:hs) | rank t > rank h = t:h:hs | rank t == rank h = linkTrees t h : hs | rank t < rank h = error "insert: invalid case!" linkTrees :: Ord a => Tree a -> Tree a -> Tree a linkTrees t1 t2@(Node r x ts) | root t1 < root t2 = linkTrees t2 t1 | otherwise = Node (r+1) x (t1:ts) fromList :: Ord a => [a] -> Heap a fromList = foldr insert empty union :: Ord a => Heap a -> Heap a -> Heap a union h1 h2 = reverse $ reverse h1 `add` reverse h2 where add (t1:t2:t1s) t2s -- take care of the carry bit | rank t1 == rank t2 = add (linkTrees t1 t2 : t1s) t2s add [] t2s = t2s add t1s [] = t1s add (t1:t1s) (t2:t2s) | rank t1 == rank t2 = add (linkTrees t1 t2 : t1s) t2s | rank t1 < rank t2 = t1 : add t1s (t2:t2s) | rank t1 > rank t2 = t2 : add (t1:t1s) t2s deleteMin :: Ord a => Heap a -> Heap a deleteMin h = delete minTree h `union` children minTree where minTree = minimumBy (compare `on` root) h uncons :: Ord a => Heap a -> Maybe (a, Heap a) uncons h = do min <- findMin h pure (min, deleteMin h) data Entry p a = Entry { priority :: p, payload :: a } deriving Show instance Eq p => Eq (Entry p a) where (Entry p1 _) == (Entry p2 _) = p1 == p2 instance Ord p => Ord (Entry p a) where (Entry p1 _) <= (Entry p2 _) = p1 <= p2 data Point = Point { y :: !Int, x :: !Int } deriving (Eq, Ord, Show) data PeopleKind = Binary | Decimal deriving Eq newtype Map = Map { getMap :: (V.Vector (V.Vector PeopleKind)) } deriving Show instance Show PeopleKind where show Binary = "binary" show Decimal = "decimal" readMap :: Int -> Int -> IO Map readMap r c = do rows <- forM [1..r] $ \_ -> do row <- map readCell <$> getLine pure (V.fromListN c row) pure $ Map (V.fromList rows) where readCell :: Char -> PeopleKind readCell c = case c of '0' -> Binary '1' -> Decimal _ -> error "Map invalid!" readFromTo :: IO (Point, Point) readFromTo = do [fy, fx, ty, tx] <- map read . words <$> getLine pure (Point (fy-1) (fx-1), Point (ty-1) (tx-1)) reachable :: PeopleKind -> Map -> Point -> Point -> Bool reachable kind grid from to = go S.empty (singleton entry0) where entry0 = Entry (0 + estimate from to, 0) from go explored frontier = case uncons frontier of Nothing -> False Just (Entry (_, cost) point, frontier') | point == to -> True | point `S.member` explored -> go explored frontier' | otherwise -> let successors = map (mkEntry cost) $ neighbors kind grid point in go (S.insert point explored) (frontier' `union` fromList successors) mkEntry c s = Entry (c+1 + estimate s to, c+1) s estimate :: Point -> Point -> Double estimate (Point y1 x1) (Point y2 x2) = sqrt . fromIntegral $ (y2 - y1)^2 + (x2 - x1)^2 neighbors :: PeopleKind -> Map -> Point -> [Point] neighbors k (Map m) (Point y x) = catMaybes [left, right, top, bottom] where left = kindOk y (x-1) right = kindOk y (x+1) top = kindOk (y-1) x bottom = kindOk (y+1) x kindOk y x = do kind <- m V.!? y >>= (V.!? x) guard (kind == k) pure (Point y x) main :: IO () main = do [rows, cols] <- map read . words <$> getLine grid <- readMap rows cols queries <- read <$> getLine forM_ [1..queries] $ \_ -> do (from, to) <- readFromTo let kind = kindAt grid from if reachable kind grid from to then print kind else putStrLn "neither" where kindAt (Map m) (Point y x) = m V.! y V.! x

2 2

Reactive and Event-Based Languages and Systems (REBLS 2020) -- Call for Papers
by Ivan Perez 23 May '20

23 May '20

CALL FOR PAPERS 7th Workshop on Reactive and Event-based Languages and Systems (REBLS 2020) co-located with the SPLASH Conference Chicago, Illinois, USA Sun 15 - Fri 20 November 2020 Website: https://2020.splashcon.org/home/rebls-2020 IMPORTANT DATES Submission Deadline: 24 Jul 2020 Author Notification: 24 Aug 2020 Final Submission Deadline: 25 Sep 2020 INTRODUCTION Reactive programming and event-based programming are two closely related programming styles that are becoming more important with the ever increasing requirement for applications to run on the web or on mobile devices, and the advent of advanced High-Performance Computing (HPC) technology. A number of publications on middleware and language design -- so-called reactive and event-based languages and systems (REBLS) -- have already seen the light, but the field still raises several questions. For example, the interaction with mainstream language concepts is poorly understood, implementation technology is still lacking, and modularity mechanisms remain largely unexplored. Moreover, large applications are still to be developed, and, consequently, patterns and tools for developing large reactive applications are still in their infancy. This workshop will gather researchers in reactive and event-based languages and systems. The goal of the workshop is to exchange new technical research results and to better define the field by developing taxonomies and discussing overviews of the existing work. We welcome all submissions on reactive programming, functional reactive programming, and event- and aspect- oriented systems, including but not limited to: * Language design, implementation, runtime systems, program analysis, software metrics, patterns and benchmarks. * Formal models for reactive and event-based programming. * Study of the paradigm: interaction of reactive and event-based programming with existing language features such as object-oriented programming, pure functional programming, mutable state, concurrency. * Modularity and abstraction mechanisms in large systems. * Advanced event systems, event quantification, event composition, aspect-oriented programming for reactive applications. * Functional Reactive Programming (FRP), self-adjusting computation and incremental computing. * Synchronous languages, modeling real-time systems, safety-critical reactive and embedded systems. * Applications, case studies that show the efficacy of reactive programming. * Empirical studies that motivate further research in the field. * Patterns and best-practices. * Related fields, such as complex event processing, reactive data structures, view maintenance, constraint-based languages, and their integration with reactive programming. * Implementation technology, language runtimes, virtual machine support, compilers. * IDEs, Tools. The format of the workshop is that of a mini-conference. Participants can present their work in slots of 30 mins with Q&A included. Because of the declarative nature of reactive programs, it is often hard to understand their semantics just by looking at the code. We therefore also encourage authors to use their slots for presenting their work based on live demos. SUBMISSIONS REBLS encourages submissions of two types of papers: * Full papers: papers that describe complete research results. These papers will be published in the ACM digital library. * In-progress papers: papers that have the potential of triggering an interesting discussion at the workshop or present new ideas that require further systematic investigation. These papers will not be published in the ACM digital library. Format: * Submissions should use the ACM SIGPLAN Conference acmart Format with the two-column, sigplan Subformat, 10 point font, using Biolinum as sans-serif font and Libertine as serif font. All submissions should be in PDF format. If you use LaTeX or Word, please use the ACM SIGPLAN acmart Templates. The page http://www.sigplan.org/Resources/Author/#acmart-format contains instructions for authors, and a package that includes an example file acmart-sigplan.tex. * Authors are required to explicitly specify the type of paper in the submission (i.e., full paper, in-progress paper). * Full papers can be *up to* 12 pages in length, excluding references. In-progress papers can be *up to* 6 pages, excluding references. Papers do not need to make use of all pages, but they will be summarily rejected if they exceed the page limits. Instructions for the Authors: * Papers should be submitted through: https://rebls20.hotcrp.com/ * For fairness reasons, all submitted papers should conform to the formatting instructions. Submissions that violate these instructions will be summarily rejected. * Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. * Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLAN’s Republication Policy (http://www.sigplan.org/Resources/Policies/Republication) Submitters should also be aware of ACM’s Policy and Procedures on Plagiarism. * All submissions are expected to comply with the ACM Policies for Authorship detailed at https://www.acm.org/publications/authors/information-for-authors. PROGRAM COMMITTEE Ivan Perez (PC Chair; NIA) Alan Jeffrey, Mozilla Research. Christiaan Baaij, QBayLogic. César Sánchez, IMDEA Software. Daniel Winograd-Cort, Target Corp. Edward Amsden, Black River Software, LLC. Guerric Chupin, University of Nottingham. Heinrich Apfelmus. Jonathan Thaler, University of Applied Sciences Vorarlberg. Louis Mandel, IBM Research. Manuel Bärenz, sonnen eServices GmbH. Marc Pouzet, Université Pierre et Marie Curie. Mark Santolucito, University of Yale. Neil Sculthorpe, University of Nottingham Trent. Noemi Rodrigues, Pontifícia Universidade Católica do Rio de Janeiro Oleksandra Bulgakova, Sukhomlynsky Mykolaiv National University Patrick Bahr, University of Copenhagen Takuo Watanabe, Tokyo Institute of Technology Tetsuo Kamina, Oita University Tom Van Cutsem, Nokia Bell Labs Yoshiki Ohshima, HARC / Y Combinator Research ORGANIZING COMMITTEE Guido Salvaneschi, TU Darmstadt, Germany Wolfgang De Meuter, Vrije Universiteit Brussel, Belgium Patrick Eugster, Universita della Svizzera Italiana, Switzerland Francisco Sant'Anna, Rio de Janeiro State University, Brazil Lukasz Ziarek, SUNY Buffalo, United States For any questions, please use the form on the website or contact the Chair at ivan.perezdominguez(a)nasa.gov.

1 0

Munich Virtual Haskell Meeting, 2020-05-25 @ 19:30
by Leah Neukirchen 22 May '20

22 May '20

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 25 at 19:30. **Due to curfew in Bavaria, this meeting will take place online!** For details see here: http://muenchen.haskell.bayern/dates.html A Google Meet link to join the room will be provided on Monday. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

To much symbols in dll
by Kees Bleijenberg 22 May '20

22 May '20

After a lot of trying I finally got my windows dll working (used by a Qt app). But after adding the package (aeson) I get: ld.exe: Error: export ordinal too large: 97839 There are a few messages about this problem. People talk about split-dll and gen-dll. But both seems more for building ghc itself. I tried gen-dll, but couldn't get it to work. I wonder if there is a solution for this problem? Kees

1 0

how to simplify ressources access and pipes steam
by PICCA Frederic-Emmanuel 21 May '20

21 May '20

Hello, I am writing a software which do some data treatement from hdf5 files. In order to access the data which are stored in arrays, I need to open and closes ressources. This is the purpose of the withHdf5PathP function. given a file f and a UhvPath I end up with this withUhvPathP :: (MonadSafe m, Location l) => l -> UhvPath -> ((Int -> IO Geometry) -> m r) -> m r withUhvPathP f (UhvPath m o d g w) gg = withHdf5PathP f m $ \m' -> withHdf5PathP f o $ \o' -> withHdf5PathP f d $ \d'-> withHdf5PathP f g $ \g' -> withHdf5PathP f w $ \w' -> gg (\j -> do mu <- get_position m' j omega <- get_position o' j delta <- get_position d' j gamma' <- get_position g' j wavelength <- getValueWithUnit w' 0 angstrom let positions = Data.Vector.Storable.fromList [mu, omega, delta, gamma'] let source = Source wavelength pure $ Geometry Uhv source positions Nothing) then I use this like this forever $ do (Chunk fp from to) <- await withFileP (openH5 fp) $ \f -> withHdf5PathP f imgs $ \dimgs -> withUhvPathP f dif $ \getDiffractometer -> withSamplePathP f samp $ \getSample -> forM_ [from..to-1] (\j -> yield =<< liftIO (DataFrameHkl <$> pure j <*> get_image' det dimgs j <*> getDiffractometer j <*> getSample j)) so once I open the resources, I use the getDiffratometer ((Int -> IO Geometry) -> m r) function give the position on the stream and it return the value at the j position. the purpose of this is to open the ressources only once at the begining and then send the values in a Pipe via the yield function of pipes package. I hope, I was clear. 1) I find the withUhvPathP sort of ugly, and I would like to know if it could be written more elegantly, because I will need to write a lot's of these function for different types. 2) It is the right way to design a solution to my problem (open ressources and send each values into a stream). thanks for you attention. Frederic

4 5

Workshop on Logic Programming: Trends, Extensions, Applications, 28-29 May 2020
by Ekaterina Komendantskaya 19 May '20

19 May '20

We invite participants to the on-line workshop on * Trends, Extensions, Applications and Semantics of Logic Programming* Logic programming is a framework for expressing programs, propositions and relations as Horn clause theories, and for automatic inference in these theories. Horn clause theories are famous for their well-understood declarative semantics, in which models of logic programs are given inductively or coinductively. At the same time, Horn clauses give rise to efficient inference procedures, usually involving resolution. Logic programming found applications in type inference, verification, and AI. While logic programming was originally conceived for describing simple propositional facts, it was extended to account for much more complex theories. This includes first-order theories, higher-order theories, inductive and coinductive data, and stochastic/probabilistic theories. The aim of this workshop is to bring together researchers that work on extensions of logic programming and inference methods, and to foster an exchange of methods and applications that have emerged in different communities. Keynote talk: *Dale Miller*. Structural Proof-Theory and Logic Programming <https://www.coalg.org/tease-lp/2020/dale-miller-structural-proof-theory-and…> Invited tutorial: *Uli Sattler*.* Description Logics and Ontology Languages - an introduction and overview* In light of COVID-19, we organise TEASE-LP as a virtual workshop and online-only event. To achieve broad participation, we use three different mediums: Discussion Forum, Pre-recorded lightning talks, Live sessions with invited and contributed live talks. Further details can be found here: https://www.coalg.org/tease-lp/workshop-schedule/. Registration is free, but we require all participants to register at https://teaselp.flarum.cloud/ For any further queries, please contact the organisers: Henning Basold <henning(a)basold.eu> Katya Komendantskaya <ek19(a)hw.ac.uk>

1 0