September 2018 - Haskell-Cafe

ANN: proto-lens-0.4.0.0
by Judah Jacobson 10 Sep '18

10 Sep '18

I'm pleased to announce the release of proto-lens-0.4.0.0. The library provides an API for protocol buffers, a language-independent binary file format. Cabal and Stack projects can use proto-lens to automatically generate Haskell source bindings from the original protocol buffer specifications. Some significant changes in this new release include: - Simplifying the overloaded lens instances to improve readability and type error messages (along with the associated release of lens-labels-0.3.0.0) - Switching to a custom class for default messages - Hiding the internals of generated message types - Making the Show instances more readable and concise - Splitting the Cabal support into finer-grained packages, for better integration with Nix and Bazel For general library documentation and tutorials: https://google.github.io/proto-lens/ For assistance in migrating from earlier versions: https://github.com/google/proto-lens/wiki/Migration-Guide For detailed changelogs: https://hackage.haskell.org/package/proto-lens/changelog https://hackage.haskell.org/package/proto-lens-protoc/changelog Best, -Judah

1 0

Mathematics of Program Construction (MPC), Portugal, 2019
by Graham Hutton 10 Sep '18

10 Sep '18

Dear all, The next Mathematics of Program Construction (MPC) conference will be held in the historic city of Porto, Portugal in October 2019, co-located with the Symposium on Formal Methods (FM). Please share, and submit your best papers! Best wishes, Graham Hutton Program Chair, MPC 2019 ====================================================================== 13th International Conference on Mathematics of Program Construction 7-9 October 2019, Porto, Portugal Co-located with Formal Methods 2019 https://tinyurl.com/MPC-Porto ====================================================================== BACKGROUND: The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. MPC 2019 will be held in Porto, Portugal from 7-9 October 2019, and is co-located with the International Symposium on Formal Methods, FM 2019. Previous conferences were held in Königswinter, Germany (2015); Madrid, Spain (2012); Québec City, Canada (2010); Marseille, France (2008); Kuressaare, Estonia (2006); Stirling, UK (2004); Dagstuhl, Germany (2002); Ponte de Lima, Portugal (2000); Marstrand, Sweden (1998); Kloster Irsee, Germany (1995); Oxford, UK (1992); Twente, The Netherlands (1989). SCOPE: MPC seeks original papers on mathematical methods and tools put to use in program construction. Topics of interest range from algorithmics to support for program construction in programming languages and systems. Typical areas include type systems, program analysis and transformation, programming language semantics, security, and program logics. The notion of a 'program' is interpreted broadly, ranging from algorithms to hardware. Theoretical contributions are welcome, provided that their relevance to program construction is clear. Reports on applications are welcome, provided that their mathematical basis is evident. We also encourage the submission of 'programming pearls' that present elegant and instructive examples of the mathematics of program construction. IMPORTANT DATES: Abstract submission 26th April 2019 Paper submission 3rd May 2019 Author notification 14th June 2019 Camera ready copy 12th July 2019 Conference 7-9 October 2019 SUBMISSION: Submission is in two stages. Abstracts (plain text, maximum 250 words) must be submitted by 26th April 2019. Full papers (pdf, formatted using the llncs.sty style file for LaTex) must be submitted by 3rd May 2019. There is no prescribed page limit, but authors should strive for brevity. Both abstracts and papers will be submitted using EasyChair. Papers must present previously unpublished work, and not be submitted concurrently to any other publication venue. Submissions will be evaluated by the program committee 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. Accepted papers must be presented in person at the conference by one of the authors. The proceedings of MPC 2019 will be published in the Lecture Notes in Computer Science (LNCS) series, as with all previous instances of the conference. Authors of accepted papers will be expected to transfer copyright to Springer for this purpose. After the conference, authors of the best papers from MPC 2019 and MPC 2015 will be invited to submit revised versions to a special issue of Science of Computer Programming (SCP). For any queries about submission please contact the program chair, Graham Hutton <graham.hutton(a)nottingham.ac.uk>. PROGRAM COMMITTEE: Patrick Bahr IT University of Copenhagen, Denmark Richard Bird University of Oxford, UK Corina Cîrstea University of Southampton, UK Brijesh Dongol University of Surrey, UK João F. Ferreira University of Lisbon, Portugal Jennifer Hackett University of Nottingham, UK William Harrison University of Missouri, USA Ralf Hinze University of Kaiserslautern, Germany Zhenjiang Hu National Institute of Informatics, Japan Graham Hutton (chair) University of Nottingham, UK Cezar Ionescu University of Oxford, UK Mauro Jaskelioff National University of Rosario, Argentina Ranjit Jhala University of California, San Diego, USA Ekaterina Komendantskaya Heriot-Watt University, UK Bernhard Möller University of Augsburg, Germany Shin-Cheng Mu Academia Sinica, Taiwan Mary Sheeran Chalmers University of Technology, Sweden Alexandra Silva University College London, UK Georg Struth University of Sheffield, UK VENUE: The conference will be held at the Alfândega Porto Congress Centre, a 150 year old former custom's house located in the historic centre of Porto on the bank of the river Douro. The venue was renovated by a Pritzer prize winning architect and has received many awards. LOCAL ORGANISERS José Nuno Oliveira University of Minho, Portugal For any queries about local issues please contact the local organiser, José Nuno Oliveira <jno(a)di.uminho.pt>. ====================================================================== 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] ANN: leancheck-v0.7.2, enumerative QuickCheck-like testing
by Rodrigo Stevaux 08 Sep '18

08 Sep '18

Hi, nice to see a fellow Brazilian. How does your work differ from QuickCheck?

2 1

Re: [Haskell-cafe] ANN: leancheck-v0.7.4 with providers for Tasty, Hspec and test-framework
by Rudy Matela 08 Sep '18

08 Sep '18

Hello Haskell-Café, A new version of LeanCheck is out: v0.7.4. LeanCheck is a property testing library (like QuickCheck) that tests values enumeratively rather than at random (unlike QuickCheck). _Whats new?_ I have created providers to make it easy to incorporate LeanCheck properties in Tasty, Hspec and test-framework test suites. This is optional and provided in separate packages: LeanCheck can still be used alone. LeanCheck and its framework providers are available on Hackage. You can install them with: $ cabal install leancheck $ cabal install tasty-leancheck $ cabal install hspec-leancheck $ cabal install test-framework-leancheck Check out the README files for examples of use: * https://github.com/rudymatela/leancheck * https://github.com/rudymatela/tasty-leancheck * https://github.com/rudymatela/hspec-leancheck * https://github.com/rudymatela/test-framework-leancheck Here's a sneak peek of LeanCheck+Tasty: ## Test program import Test.Tasty import Test.Tasty.LeanCheck as LC import Data.List main :: IO () main = defaultMain tests tests :: TestTree tests = testGroup "Test properties checked by LeanCheck" [ LC.testProperty "sort == sort . reverse" $ \list -> sort (list :: [Int]) == sort (reverse list) , LC.testProperty "Fermat's little theorem" $ \x -> ((x :: Integer)^7 - x) `mod` 7 == 0 -- the following property do not hold , LC.testProperty "Fermat's last theorem" $ \x y z n -> (n :: Integer) >= 3 LC.==> x^n + y^n /= (z^n :: Integer) ] ## Output for the test program $ ./test Test properties checked by LeanCheck sort == sort . reverse: OK +++ OK, passed 200 tests. Fermat's little theorem: OK +++ OK, passed 200 tests. Fermat's last theorem: FAIL *** Failed! Falsifiable (after 71 tests): 0 0 0 3 1 out of 3 tests failed (0.00s) You can't see it here, but Tasty's output is highlighted in colours: "FAIL" appears in red so you can quickly see which properties failed. Best Regards, Rudy

1 0

common class for Set (and Map, resp.) implementations with different constraints on the keys
by Johannes Waldmann 07 Sep '18

07 Sep '18

Dear Cafe, we have Data.Set, Data.IntSet, Data.HashSet, and they all have similar API, where the only difference is the constraint on the elements. (Same thing for maps.) Can we unify this as follows: {-# language ConstraintKinds, TypeFamilies #-} class SetC s where type Con s :: * -> Constraint singleton :: (Con s a) => a -> s a foldMap :: (Con s a, Monoid m) => (a -> m) -> s a -> m ... Then for Data.Set, we write instance SetC S.Set where type Con S.Set = Ord ; ... It seems to work, and it allows me to write polymorphic code, and switch implementations from the top. Full source: https://gitlab.imn.htwk-leipzig.de/waldmann/pure-matchbox/tree/master/src/D… Example use case (switch implementation): https://gitlab.imn.htwk-leipzig.de/waldmann/pure-matchbox/blob/master/src/M… Still, there are some clumsy corners in this code, perhaps you can help: * for instance SetC HashSet, there are two constraints. I want to write type Con HashSet = \ e -> (Hashable e, Eq, e) but this does not work (there is no "type lambda"?) * for maps, I want to write class (forall k . Foldable m k) => MapC m but this seems impossible now (This is would work with -XQuantifiedConstraints ?) * in some other code using the same idea (the class exports the constraint), I had an instance where the constraint was empty. Again, I cannot write type Con Foo = \ s -> () - J.W.

4 4

Passing creation flags to CreateProcess on windows
by Yotam Ohad 07 Sep '18

07 Sep '18

Hello cafe, I'm working on a small debugger so I would like to use the winapi CreateProcess function with the appropriate flags for debugging. Unfortunately, it seems that in Haskell <http://hackage.haskell.org/package/process-1.6.4.0/docs/System-Process.html…>there is no way to pass the flags. I would like to not use LoadLibrary to get every function I need. Thanks Yotam

2 1

Stack project, dependency with build flags
by John Z. 06 Sep '18

06 Sep '18

Hi everyone, I'll try with tl:dr; first: I have a project with a dependency that -on my system- needs a build flag, in order to correctly link against its native dependencies. What is a proper way to set up a project like this? A longer explanation: My project uses `ncurses` library and I'm running Arch. There seems to be some religious opinion going around about the layout of ncurses headers in /usr/include, and -naturally- Arch and `ncurses` disagree. Fortunately, author of `ncurses` included a build flag to allow (easy) build on systems which follow the 'wrong' layout. Thing is, I couldn't figure out how to add this configuration to the .cabal of my own project, so for now, I'm stuck with a Makefile that invokes `stack` commands with `--flag ncurses:force-narrow-library`. I looked in the manual and there doesn't seem to be a way to handle this aside the commandline argument. So this got me thinking - is there a different way projects like these are supposed to be organized? For example, am I supposed to check out `ncurses` as a submodule of my project, then replicate this build flag on my own project and 'pass it down' somehow? Any tips are highly appreciated; I'm really not proficient with organizing stack projects properly. Cheers! -- "That gum you like is going to come back in style."

3 4

how to Enumerate without lists?
by Johannes Waldmann 06 Sep '18

06 Sep '18

Dear Cafe (again), I was trying to write sum $ map (^ 2) $ [ 1 :: Int .. 10^8 ] in a list-free style getSum $ foldMap (Sum . (^ 2)) $ [ 1 :: Int .. 10^8 ] This avoids building an intermediate list (of squares) but it will allocate, since foldMap uses foldr (by default, and it's not overridden for lists) The conclusion would be: not to use lists at all. Which will be the point of my talk anyway. But here, we get a list from enumFromTo. Can we avoid that? Let's try: we just reify enumFromTo data Enumerator a = Enumerator {from :: a, to :: a} we have this for decades, it is called (a,a) in Data.Ix, and then instance Foldable Enumerator where ... Oh no, foldMap (and others) would need an Enum constraint! - J

5 5

small example for space-efficiency via lazy evaluation?
by Johannes Waldmann 05 Sep '18

05 Sep '18

Dear Cafe, I wanted to demonstrate that main = print $ sum $ map (^ 2) $ [ 1 :: Int .. 10^8 ] without any optimisations, still runs in constant space because garbage is collected immediately. Except that it does not: ghc -O0 space.hs -rtsopts -ddump-simpl ./space +RTS -M80k -A10k gives me unoptimized Core as expected, but exhausts the heap. After some experimentation, I found that replacing Prelude.sum with Data.Foldable.foldl' (+) 0 achieves what I want. I think the reason is that instance Foldable [] implements sum by foldl (non-strict). Both versions will run without any allocation as soon as we compile with -O1 . So, my question is, what do you use as a (teaching) example for space-efficiency via lazy evaluation? Preferrably a one-liner, using only standard libraries, and such that the effect is not rendered moot by -O2. - J PS: It is magic that foldl and foldl' produce identical core here? $wgo_s5we (w_s5w8 :: GHC.Prim.Int#) (ww1_s5wc :: GHC.Prim.Int#) = case GHC.Prim.==# w_s5w8 ww_s5w5 of { __DEFAULT -> jump $wgo_s5we (GHC.Prim.+# w_s5w8 1#) (GHC.Prim.+# ww1_s5wc (GHC.Prim.*# w_s5w8 w_s5w8));

2 1

Fwd: Setting RTS thread names useful?
by Michal J Gajda 05 Sep '18

05 Sep '18

It seems `GHC.Conc.labelThread` does not have corresponding `getThreadLabel`. It would be useful when redirecting all exceptions to `journald` etc. The problem might be, that this function is documented to function in debugging builds only :-(. Just like stack traces which need special options.

1 0