- Haskell-Cafe - Haskell.org

ANN: LeanCheck v1.0.0 – Enumerative Property Testing
by Rudy Matela 22 Aug '22

22 Aug '22

Hello Haskell Café, A new version of LeanCheck <https://hackage.haskell.org/package/leancheck> is out (v1.0.0 <https://hackage.haskell.org/package/leancheck>). LeanCheck is a property testing library (like QuickCheck) that tests values enumeratively. *Example.* Here is a simple example of LeanCheck in action showing that sorting is idempotent and list union is not commutative: > import Test.LeanCheck > import Data.List (sort, union) > check $ \xs -> sort (sort xs) == sort (xs::[Int]) +++ OK, passed 200 tests. > check $ \xs ys -> xs `union` ys == ys `union` (xs::[Int]) *** Failed! Falsifiable (after 4 tests): [] [0,0] LeanCheck works on all types that are instances of the Listable typeclass and is able to derive instances automatically using either Template Haskell or GHC.Generics. See LeanCheck’s Haddock documentation <https://hackage.haskell.org/package/leancheck/docs/Test-LeanCheck.html> for more details. LeanCheck is compatible with Hspec <https://hackage.haskell.org/package/hspec-leancheck>, Tasty <https://hackage.haskell.org/package/tasty-leancheck> and test-framework <https://hackage.haskell.org/package/test-framework-leancheck>. *What's new?* Version 1.0.0 signalizes stability in the API. LeanCheck has not actually changed much in the past couple of years and there are no significant differences between the early 0.9 series. *Installing.* You can find LeanCheck on Hackage <https://hackage.haskell.org/package/leancheck> or GitHub <https://github.com/rudymatela/leancheck>. It is also tracked on Stackage <https://www.stackage.org/package/leancheck>. You can install it with: $ cabal install leancheck – Rudy

1 0

[ANN]: dunai-0.9.0, dunai-test-0.9.0, bearriver-0.13.6
by Ivan Perez 21 Aug '22

21 Aug '22

Hi everyone! I've just released version 0.9.0 of the dunai libraries, which comes with version 0.13.6 of bearriver. For those unfamiliar, dunai is a reactive programming library structured around a notion of Monadic Stream Functions <https://dl.acm.org/doi/abs/10.1145/3241625.2976010>. dunai can be used to implement other reactive and FRP frameworks on top, including Classic FRP and Arrowized FRP variants. bearriver itself is an API-compatible implementation of Yampa. dunai also comes with a QuickCheck-based temporal testing library, and can be connected with the testing system haskell-titan. All versions of GHC from 7.6 to 9.4 are supported. *Release information* This is mainly a maintenance release. Among other changes, this version improves the documentation in dunai-test. Additionally, a function that was exposed unnecessarily is being deprecated in preparation for its future removal. - Release: https://github.com/ivanperez-keera/dunai/releases/tag/v0.9.0. - Hackage: - dunai: https://hackage.haskell.org/package/dunai. - dunai-test: https://hackage.haskell.org/package/dunai-test - bearriver: https://hackage.haskell.org/package/bearriver - Repo: https://github.com/ivanperez-keera/dunai. *Upcoming changes* We are synchronizing releases with the Yampa project to ensure that bearriver incorporates any changes added to Yampa. Additionally, the goal is to eventually use Yampa's tests also to give bearriver full test coverage. Two changes are being discussed that will potentially affect users: - The introduction of a new constraint in VectorSpace in simple-affine-space would alter the type constraints of some functions. See #298 <https://github.com/ivanperez-keera/dunai/issues/298>. - A re-structuring of the API to better reflect the purpose of the implementation. This could also lead to a division of dunai into multiple libraries. See #305 <https://github.com/ivanperez-keera/dunai/issues/305>. The next release is expected to be published on October 21, 2022. Happy Haskelling! Ivan

1 0

[ANNOUNCE] GHC 9.4.1 is now available
by Ben Gamari 21 Aug '22

21 Aug '22

The GHC developers are very pleased to announce the availability of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.1 This release includes: - A new profiling mode, `-fprof-late`, which adds automatic cost-center annotations to all top-level functions *after* Core optimisation has run. This provides informative profiles while interfering significantly less with GHC's aggressive optimisations, making it easier to understand the performance of programs which depend upon simplification.. - A variety of plugin improvements including the introduction of a new plugin type, *defaulting plugins*, and the ability for typechecking plugins to rewrite type-families. - An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing. - Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs. - Generalisation of a variety of primitive types to be levity polymorphic. Consequently, the `ArrayArray#` type can at long last be retired, replaced by standard `Array#`. - Introduction of the `\cases` syntax from [GHC proposal 0302]. - A complete overhaul of GHC's Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO. - Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects. - A refactoring of GHC's error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support. - Significant compile-time improvements to runtime and memory consumption. - On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions. - Reintroduction of deep subsumption (which was previously dropped with the *simplified subsumption* change) as a language extension. - ... and much more. See the [release notes] for a full accounting. Note that, as 9.4.1 is the first release for which the released artifacts will all be generated by our Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-c… [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

5 6

[ANN] cabal-clean (new tool)
by Andreas Abel 19 Aug '22

19 Aug '22

=== Wondering where your disk space goes with too many Haskell projects compiled with too many GHC versions? === https://hackage.haskell.org/package/cabal-clean https://github.com/andreasabel/cabal-clean `cabal-clean` is a small executable that removes outdated cabal build artifacts from `dist-newstyle`. A build tree is considered outdated if there is one with either - a newer version of the package you are building, or - a newer minor version of the GHC compiler. In contrast to `cabal clean`, the tool `cabal-clean` retains the latest build trees for each GHC major version. Thus, it is geared towards multi-GHC development. Example: (self-applied to cabal-clean's build directory) --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 The directories prefixed with --- will be deleted, the ones with +++ retained. Disclaimers: 1. cabal-clean does not check whether deletion will cause dangling references like broken symlinks etc. (Could happen if you created a symlink to an executable that resides in one of the deleted build directories.) 2. cabal-clean does not read nor utilize information from the .cabal file. 3. Calls `du` ("disk usage"), so, might not work on Windows. Enjoy, Andreas

6 6

Ambiguous type variable with lenses
by Henry Laxen 18 Aug '22

18 Aug '22

-- run this with: ghci -package microlens-platform T7.hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleInstances #-} module T7 where import Lens.Micro.Platform type Lenstype f a b = (b -> f b) -> a -> f a data A = A { _a1 :: Int , _a2 :: String} deriving (Show) $(makeLenses ''A) class B a where lensB1 :: (Functor f) => Lenstype f a Int lensB2 :: (Functor f) => Lenstype f a String instance B A where lensB1 = a1 lensB2 = a2 xa = A 1 "one" ya1 = xa ^. a1 ya2 = xa ^. lensB1 test1 = ya1 == ya2 -- True -- But I would like to use a type variable for the String field of A data C b = C { _c1 :: Int , _c2 :: b} deriving (Show) $(makeLenses ''C) -- So next I define: class D a b where -- Need MultiParamTypeClasses here lensD1 :: (Functor f) => Lenstype f a Int -- Need AllowAmbiguousTypes here lensD2 :: (Functor f) => Lenstype f a b instance D (C b) b where -- Need FlexibleInstances here lensD1 = c1 lensD2 = c2 xc1 = C 1 "one" :: C String xc2 = C 1 'o' :: C Char yc1 = xc1 ^. c1 :: Int yc2 = xc2 ^. c1 :: Int test2 = yc1 == yc2 -- True -- All good until here. Now the trouble begins. If you uncomment the next two lines you get: -- zc1 = xc1 ^. lensD1 :: Int -- zc2 = xc2 ^. lensD1 :: Int -- T7.hs:62:14-19: error: -- • Ambiguous type variable ‘b1’ arising from a use of ‘lensD1’ -- prevents the constraint ‘(D (C String) b1)’ from being solved. -- Probable fix: use a type annotation to specify what ‘b1’ should be. -- These potential instance exist: -- instance D (C b) b -- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 -- • In the second argument of ‘(^.)’, namely ‘lensD1’ -- In the expression: xc1 ^. lensD1 :: Int -- In an equation for ‘zc1’: zc1 = xc1 ^. lensD1 :: Int -- | -- 62 | zc1 = xc1 ^. lensD1 :: Int -- | ^^^^^^ -- T7.hs:63:14-19: error: -- • Ambiguous type variable ‘b0’ arising from a use of ‘lensD1’ -- prevents the constraint ‘(D (C Char) b0)’ from being solved. -- Probable fix: use a type annotation to specify what ‘b0’ should be. -- These potential instance exist: -- instance D (C b) b -- -- Defined at /home/henry/haskell/dev/T7.hs:44:10 -- • In the second argument of ‘(^.)’, namely ‘lensD1’ -- In the expression: xc2 ^. lensD1 :: Int -- In an equation for ‘zc2’: zc2 = xc2 ^. lensD1 :: Int -- | -- 63 | zc2 = xc2 ^. lensD1 :: Int -- | ^^^^^^ -- But zc1 and zc2 don't care what is in the second slot. I would -- like to store different types in the second slot of C, but the -- first slot of C will always be an Int. Is there any way to -- manipulate the first slot alone? I got some compiler "suggestions" -- concernting RankNTypes and QuantifiedConstraints but nothing I -- tried ended up working. -- Thanks in advance for your help. -- Henry Laxen

2 2

Web server with dynamic data
by Hans Georg Schaathun 16 Aug '22

16 Aug '22

Hi, I have been fiddling with this idea for some time, and I wonder if this may be the right place to ask a rather probing question!? It has been some years since my last visit to the list. I have been searching for examples using functional reactive programming to make web servers, but this proves surprisingly hard to find. I found the netwire library, but given that the last update was 2011 I am not sure I want to risk that ... So maybe I was asking the wrong question. I have a rather complex system of RDF Graphs (using Swish), with reasoners making derived graphs, and updates being made only on the original graphs. There are multiple constituent graphs to avoid having to recompute everything upon update. Now I was thinking that this looks like a typical case for FRP, with each graph a Behaviour, recomputing derived graph only when the source behaviour changes. I am not sure if I am right. Any opinions? The second part of this is the web server to allow queries (read and update) to the RDF Graphs. The first prototype uses Scotty with STM for storage, but when I add more constituent graphs, I really do not want an update to block access to other constituent graphs, which is what I thought I could avoid in an FRP model. Without much experience writing interactive stuff in Haskell, I cannot figure out how to wire the interaction between Scotty and either netwire or banana which are the two FRP libraries I have tried to comprehend. Are there any examples out there to look at? I am not really committed to any library or paradigm, except for RDF and Swish, so any ideas will be welcome, even pointing me away from everything I thought I needed ... Thanks for reading, :-- George

1 0

IFL22: Early registration deadline August 15th
by Pieter Koopman 15 Aug '22

15 Aug '22

*IFL 2022Frederiksberg Campus of Faculty of Science, UCPH, CopenhagenAugust 31s-September 2nd, 2022* *Early registration deadline: August 15th AoE * *See **https://ifl22.github.io/* <https://ifl22.github.io/>* for more information.* *CALL FOR PARTICIPATION:* The 34th Symposium on Implementation and Application of Functional Languages (IFL 2022) Copenhagen, August 31st-September 2nd, 2022 *Important dates* Submission deadline of draft papers August 8th, 2022 (EXPIRED) Notification of acceptance August 9th, 2022 (EXPIRED) Early registration deadline August 15th, 2022 (AoE) Late registration deadline August 31st, 2022, 12:59 CET (UTC+2) IFL Symposium August 31st - September 2nd, 2022 (We-Fr) *Scope* The goal of IFL is to bring together researchers and developers actively engaged in the implementation and application of functional programming languages and function-oriented programming. IFL 2022 is held in beautiful Copenhagen, Denmark and is a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional programming languages and function-oriented programming. *Invited speakers* IFL 2022 is pleased to announce keynote talks by the following three invited speakers: * Peter Sestoft, Professor, Head of Department, IT University of Copenhagen, Denmark: "Abstract machines and functional language implementation" * Lennart Augustsson, Principal Programmer, Epic Games: "Verse - a new functional-logic language" * Thomas Gazagnaire, Chief Technology Officer and co-founder, Tarides: "Talk title to be announced" *Venue and registration* The symposium will be held physically on the Frederiksberg Campus of the Faculty of Science at the University of Copenhagen. Days 1 and 2 (August 31st and September 1st) will be in meeting room A2-84.01 at Thorvaldsensvej 40. Day 3 (September 2nd) will be in the Celebration Auditorium at Bülowsvej 17. For registration and fees, please consult the symposium web site at https://ifl22.github.io/. Please notice that the early registration date is August 15, 2022 (AoE). *Accepted papers* * Asynchronous Shared Data Sources. Mart Lubbers, Haye Böhm, Pieter Koopman and Rinus Plasmeijer. * Heuristics-based Type Error Diagnosis for Haskell: the case of type families. Niels Kwadijk and Jurriaan Hage. * Verified Technology Mapping in an Agda DSL for Circuit Design. João Paulo Pizani Flor and Wouter Swierstra. * Creating Interactive Visualizations of TopHat Programs. Mark Gerarts, Marc de Hoog, Nico Naus and Tim Steenvoorden. * An SQL Frontend on top of OCaml for Data Analysis. Yan Dong, Yahui Song and Wei-Ngan Chin. * A Structure Editor with Type-Safe Copy/Paste. Hans Hüttel, Christoffer Lind Andersen, Nana Gjerulf Sandberg, Anja Elisasen Lumholtz Nielsen and Peter Mikkelsen. * How to fold and color a map: Comparing Use-Cases of Tree-Fold vs Fold-Left. Jim Newton. * Compiling a functional array language with non-semantic memory information. Philip Munksgaard, Cosmin Oancea and Troels Henriksen. * Systems of partial values and their applications in Haskell. Natasha England-Elbro. * First-Class Data Types in Shallow Embedded Domain-Specific Languages using Metaprogramming. Mart Lubbers, Pieter Koopman and Rinus Plasmeijer. * Set-theoretic Types for Erlang. Albert Schimpf, Stefan Wehr and Annette Bieniusa. * Strongly-Typed Multi-View Stack-Based Computations. Pieter Koopman and Mart Lubbers. * Ztrategic: Strategic Programming with Zippers. José Nuno Macedo, Emanuel Rodrigues, Marcos Viera and João Saraiva. * Higher-ranked region inference for polymorphic, lazy languages. Ivo Gabe de Wolff and Jurriaan Hage. * Jeopardy: An invertible functional programming language. Joachim Kristensen, Robin Kaarsgaard and Michael Kirkedal Thomsen. * The Foil: Capture-Avoiding Substitution With No Sharp Edges. Dougal Maclaurin, Alexey Radul and Adam Paszke. * Verified Causal Broadcast with Liquid Haskell. Patrick Redmond, Gan Shen, Niki Vazou and Lindsey Kuper. * Towards Inversion of Tail-recursive Term Rewriting Systems. Maria Bendix Mikkelsen, Robert Glück and Maja Hanne Kirkeby. * A Confluence and Termination Checker for Haskell Rewrite Rules. Makoto Hamana. * On Generating Out-Of-Core GPU Code for Multi-Dimensional Array Operations. Patrick van Beurden and Sven-Bodo Scholz. * Compiling Haskell for Energy Efficiency: Analysis of Individual Transformations. Bernardo Santos, João Fernandes, Maja Kirkeby and Alberto Pardo. *Post-symposium peer review * Following IFL tradition, IFL 2022 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers have been screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. Notice that it is a requirement that draft papers that are accepted for presentation be presented physically at the symposium. After the symposium the authors are invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper will be accepted or rejected for the formal proceedings. Papers that are accepted for the formal proceedings are published in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. *Peter Landin Prize* The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. *Sponsors* IFL 2022 is financially supported by - Meta (Silver sponsor), - Well-typed (Bronze sponsor), - Funktionelle Københavnere (Bronze sponsor), and - University of Copenhagen (administrative support, host). *Organisation* General chair Fritz Henglein, University of Copenhagen Program chair Martin Elsman, University of Copenhagen Communications chair Troels Henriksen, University of Copenhagen *Program committee* Laura M. Castro Universidade da Coruña, Spain David Christiansen Haskell Foundation Martin Elsman University of Copenhagen, Denmark (chair) Matthew Fluet Rochester Institute of Technology, USA Clemens Grelck Universiteit van Amsterdam, The Netherlands Zhenjiang Hu Peking University, China Robin Kaarsgaard University of Edinburgh, Scotland Gabriele Keller Utrecht University, The Netherlands Oleg Kiselyov Tohoku University, Japan Neil Mitchell Facebook Stefan Monnier Universite de Montreal, Canada Magnus Myreen Chalmers University, Sweden Cyrus Omar University of Michigan, USA Romain Péchoux University of Lorraine, Inria, France Rinus Plasmeijer Radboud University, The Netherlands Morten Rhiger Roskilde University, Denmark Peter van Roy Catholic University of Louvain, Belgium Olin Shivers Northeastern University, USA Peter Thiemann University of Freiburg, Germany Marcos Viera Universidad de la República, Uruguay Meng Wang University of Bristol, UK [image: beacon]

1 0

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Olaf Klinke 12 Aug '22

12 Aug '22

Anthony Clayden wrote: > What is your evidence that number/String is a concern here? It's all > happening in-memory. > > Whereas sending whatever to SQL then needs putting it to disk, which is > orders-of-magnitude slower. (Or is this an in-memory database?) > > This thread has already devoted more cycles to speculation than you're > going to reclaim through number formatting, methinks. Very good point. I'm fairly new to SQL, have a solution that works and started to wonder how efficient it is. Since the way data is passed to and from the DB engine affects every database interaction, for every user, I thought it might be worthwile investigating. And as I said earlier, profiling other code has proved that number parsing can make up a significant portion of a data-heavy program's CPU time. Thus it's not speculation entirely. Olaf

1 0

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Anthony Clayden 12 Aug '22

12 Aug '22

> the backend constructs a complete SQL query statement in form of a string (including the SqlValues), and hands that to the database driver to parse. Is that indeed so? > Hi Olaf, that's the usual format for any HLL to pass statements (queries or updates) to SQL. Most HLLs provide some sort of modulate/demodulate so your program doesn't see the raw numbers-as-strings, but the parsing is going on in the background. Going via CSV isn't really saving anything: the "bulk insert" is again parsing those commas and the bits in between. (A dedicated SQL engine is probably more efficient than Haskell's string handling.) AntC

3 2

Re: [Haskell-cafe] Haskell SQL backends: How is data handed over?
by Anthony Clayden 12 Aug '22

12 Aug '22

> @Olaf You mean that formatting a Scientific number as String is more efficient > than formatting an Integer/Double in its usual representation? > How about parsing? I'm not going to defend the 'efficiency' of Haskell's String formatting/parsing, but ... What is your evidence that number/String is a concern here? It's all happening in-memory. Whereas sending whatever to SQL then needs putting it to disk, which is orders-of-magnitude slower. (Or is this an in-memory database?) This thread has already devoted more cycles to speculation than you're going to reclaim through number formatting, methinks.

1 0