November 2019 - 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

Is UndecidableInstances unavoidable in heterogenous Show derivation?
by Viktor Dukhovni 30 Nov '19

30 Nov '19

I was reading: Summer School on Generic and Effectful Programming Applying Type-Level and Generic Programming in Haskell Andres Löh, Well-Typed LLP https://www.cs.ox.ac.uk/projects/utgp/school/andres.pdf and trying out the various code fragments, and was mildly surprised by the need for -XUndecidableInstances when deriving the 'Show' instance for the heterogenous N-ary product 'NP': deriving instance All (Compose Show f) xs => Show (NP f xs) Without "UndecidableInstances" I get: • Variable ‘k’ occurs more often in the constraint ‘All (Compose Show f) xs’ than in the instance head ‘Show (NP f xs)’ (Use UndecidableInstances to permit this) • In the stand-alone deriving instance for ‘All (Compose Show f) xs => Show (NP f xs)’ This is not related to automatic deriving, as a hand-crafted instance triggers the same error: instance All (Compose Show f) xs => Show (NP f xs) where show Nil = "Nil" show (x :* xs) = show x ++ " :* " ++ show xs Is there some other way of putting together the building blocks that avoids the need for 'UndecidableInstances', or is that somehow intrinsic to the type of NP construction? I guess I should also ask whether there's a way to define something equivalent to 'Compose' without 'UndecidableSuperClasses', and perhaps the two are not unrelated. [ Perhaps I should be more blasé about enabling these extensions, but I prefer to leave sanity checks enabled when possible. ] -- Viktor. {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE UndecidableSuperClasses #-} import GHC.Exts (Constraint) -- | Map a constraint over a list of types. type family All (c :: k -> Constraint) (xs :: [k]) :: Constraint where All _ '[] = () All c (x ': xs) = (c x, All c xs) -- | With @g@ a type constructor and @f@ a constraint, define @Compose f g@ as -- a contraint on @x@ to mean that @g x@ satisfies @f@. -- -- Requires: -- -- 'ConstraintKinds' -- 'FlexibleInstances' -- 'MultiParamTypeClasses' -- 'TypeOperators' -- 'UndecidableSuperClasses' -- class (f (g x)) => (Compose f g) x instance (f (g x)) => (Compose f g) x -- | Type-level 'const'. newtype K a b = K { unK :: a } deriving instance Show a => Show (K a b) -- | N-ary product over an index list of types @xs@ via an interpretation -- function @f@, constructed as a list of elements @f x@. -- data NP (f :: k -> *) (xs :: [k]) where Nil :: NP f '[] (:*) :: f x -> NP f xs -> NP f (x ': xs) infixr 5 :* -- | If we can 'show' each @f x@, then we can 'show' @NP f xs@. -- -- Requires: 'UndecidableInstances' -- deriving instance All (Compose Show f) xs => Show (NP f xs)

1 0

ANN brittany-0.12.0.0
by Evan Borden 28 Nov '19

28 Nov '19

Hello, I am happy to announce the release of brittany version 0.12.0.0. This version includes a number of fantastic improvements from many excellent contributors. Additionally brittany will soon be added back to stackage. In the meantime it can be built with the stack.yaml in its source or with cabal v2-build. https://hackage.haskell.org/package/brittany-0.12.0.0 Contributors ============ * Benjamin Kovach @5outh * Doug Beardsley @mightybyte * Evan Borden @eborden * Lennart Spitzner @lspitzner * Matt Noonan @moatt-noonan * Phil Hazelden @ChickenProp * Rupert Horlick @ruhatch * Sergey Vinokurov @sergv New Collaborators ================= You may be wondering why I am sending this message instead of Lennart. Taylor Fausak and I are taking on some of the maintenance for brittany. We will hopefully lift some of the burden from Lennart so he can remain the guiding light and driving force behind the project. Changes ========== This release includes many bug fixes, additional support for a number of syntactic constructs and a few layouting modifications. For full details check the change log on github: https://github.com/lspitzner/brittany/blob/master/ChangeLog.md Again thank you to brittany's fantastic contributors for helping making this release happen. -- Evan

2 1

[Announcement] Copilot 3.1, hard realtime C generator and runtime verification framework
by Ivan Perez 27 Nov '19

27 Nov '19

Dear all, We are very pleased to announce the release of Copilot 3.1, a stream-based DSL for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Among others, Copilot has been used at the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. This new release contains a number of bug fixes and simplifications: * The installation instructions have been updated to work with new versions of cabal and GHC. * Random stream generators were not being used and have been removed. * External functions are no longer supported by the language (to prevent side-effects in streams). * Minor bug related to labels, nested locals, and pretty printing Copilot core, have been fixed. * Code internals have been simplified for a more future proof codebase. Copilot 3.1 is available on hackage [1]. For more information, including documentation, examples and links to the source code, please visit the webpage [2]. Current emphasis is on providing better documentation, facilitating the use with other systems, and generally improving the codebase. Users are encouraged to participate by opening issues and asking questions via our github repo [3]. Kind regards, The Copilot developers: - Frank Dedden (maintainer) - Alwyn Goodloe (maintainer) - Ivan Perez (maintainer) [1] http://hackage.haskell.org/package/copilot [2] https://copilot-language.github.io [3] https://github.com/Copilot-Language/copilot

1 0

A Specification for GADTs in Haskell?
by Xuanrui Qi 26 Nov '19

26 Nov '19

Hello all, I recently came a cross a comment by Richard Eisenberg that there's actually no specification for GADTs and creating one would be a major research project (in a GHC proposal somewhere, I recall, but I don't remember exactly where). I was wondering what exactly does Richard's comment mean. What constitutes a specification for GADTs in Haskell? I suppose typing rules and semantics are necessary; what are the major roadblocks hindering the creation of a formal specification for GADTs in Haskell? Thanks! Xuanrui -- Xuanrui Qi Graduate School of Mathematics, Nagoya University https://www.xuanruiqi.com

4 3

[TFP'20] draft paper deadline open (January 10 2020) Trends in Functional Programming 2020, 13-14 February, Krakow, Poland
by Peter Achten 26 Nov '19

26 Nov '19

------------------------------------------------------------------------- Third call for papers 21st Symposium on Trends in Functional Programming tfp2020.org ------------------------------------------------------------------------- Did you miss the deadline to submit a paper to Trends in Functional Programming http://cse.chalmers.se/~rjmh/tfp/? No worries -- it's not too late! Submission is open until January 10th 2020, for a presentation slot at the event and post-symposium reviewing. The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. * TFP is moving to new winter dates, to provide an FP forum in between the annual ICFP events. * TFP offers a supportive reviewing process designed to help less experienced authors succeed, with two rounds of review, both before and after the symposium itself. Authors have an opportunity to address reviewers' concerns before final decisions on publication in the proceedings. * TFP offers two "best paper" awards, the John McCarthy award for best paper, and the David Turner award for best student paper. * This year we are particularly excited to co-locate with Lambda Days in beautiful Krakow. Lambda Days is a vibrant developer conference with hundreds of attendees and a lively programme of talks on functional programming in practice. TFP will be held in the same venue, and participants will be able to session-hop between the two events. Important Dates --------------- Submission deadline for pre-symposium review: 15th November, 2019 -- passed -- Submission deadline for draft papers: 10th January, 2020 Symposium dates: 13-14th February, 2020 Visit tfp2020.org for more information.

1 0

Munich Haskell Meeting, 2019-11-27 @ 19:30
by Leah Neukirchen 25 Nov '19

25 Nov '19

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, November 27 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-nov-2019/ Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Planet Haskell
by Joachim Breitner 22 Nov '19

22 Nov '19

Hi, I am reading planet haskell through a feed reader that pulls https://planet.haskell.org/atom.xml and I get new posts. But it seems that that https://planet.haskell.org/ is stuck in January 2019. Or, upon closer inspection, new posts _are_ on planet.haskell.org, but they are not on top. I guess in the times of reddit and slack, few people are following the planet, but maybe still some people do? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 2

Re: [Haskell-cafe] Transforming from on State-transformer to another
by Olaf Klinke 22 Nov '19

22 Nov '19

> Am 21.11.2019 um 22:56 schrieb Jacques Carette <carette(a)mcmaster.ca>: > > On 2019-Nov.-21 15:57 , Olaf Klinke wrote: >>> Is there a way to have a function of type (a -> b) -> State a c -> State >>> b c ? >> djinn says no. The reason ist that the a occurs both positively and negatively in State a c, that is, on the left and the right hand side of the -> in State. >> >>> In the particular case of interest, I am interested in is actually b -> >>> State a c -> (State (a,b) c), which is of course a special case of the >>> above. >> djinn says yes. The suggested term is >> >> \f -> \(a,b) -> let (a,c) = f a in ((a,b),c) > > > Thanks. I tried to play with the online djinn to ask about exactly this - and failed! How should I be asking? I downloaded the djinn package and built it with cabal. > > Also, something is weird about that term, since it doesn't match "b -> State a c -> (State (a,b) c)" at all. It does match "(b -> State a c) -> (State (a,b) c)" which is a completely different type (and not interesting...) Sorry, I tried to simplify djinn's output and failed. The term should be \f -> \(a,b) -> let (c,a') = f a in (c,(a',b)) :: (a -> (c, a3)) -> (a, b) -> (c, (a3, b)) where you can let a3 = a to get State a c -> State (a,b) c That is, it maps a transformer of state a into a transformer of state (a,b) that leaves the b component unchanged. Olaf

1 0

Re: [Haskell-cafe] filepath
by Johannes Waldmann 21 Nov '19

21 Nov '19

Dear Cafe, is there a library that provides an "abstract representation of file and directory pathnames"? This had been discussed before - e.g., https://mail.haskell.org/pipermail/libraries/2007-December/008769.html (it's one message of a longer thread) That message references an obsolete (?) Java library, they now have https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/nio/file/… It seems that https://hackage.haskell.org/package/filepattern-0.1.1/docs/System-FilePatte… does cover typical usage. It is based on FilePath = String, and its implementation has some "++"-ing. That indicates that an abstraction layer is missing - or, that such a layer is indeed not required? - J.W.

2 1