- Haskell-Cafe - Haskell.org

[ANN] mtl-2.3.1-rc1
by Emily Pillmore 30 Aug '22

30 Aug '22

Hi Everyone, mtl-2.3.1-rc1 ( https://github.com/haskell/mtl/releases/tag/v2.3.1-rc1 ) is up on Github. We'll give this a 2 week window for issues relating to the changelog, and then do a release. Please review and upgrade if you're interested. Backported is also a migration doc for people interested in migrating to mtl-2.3. You can find it in the repo. Special thanks to Koz and everyone else who contributed. Cheers, E

1 0

Three Haskell roles with Core Strats at Standard Chartered
by José Pedro Magalhães 28 Aug '22

28 Aug '22

Core Strats at Standard Chartered Bank are hiring Haskell developers again. We're currently looking for three developers, and we're flexible with regards to seniority / experience. The head of our group has given a talk at the Haskell Implementer’s Workshop last year where he described the team and what we do: https://www.youtube.com/watch?v=A70SN7vFsKU These roles are specifically for Applications & Services development, so expect some GUI work and plenty of stakeholder interaction. Applications should go via these links: Warsaw: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200023433 for direct employment, or CoreStratsRoles(a)sc.com for contracting London: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200023448 Singapore: https://scb.taleo.net/careersection/ex/jobdetail.ftl?job=2200017272 Shanghai: reach out to CoreStratsRoles(a)sc.com The Warsaw position is open to both contractors and direct employment, whereas the others are only open for direct employment. Standard Chartered supports (practically fully) remote working, but only from the country of payroll, and after an initial 3-month in-office period. We cover visa and relocation costs for successful employment applicants. Note that the first step of the application is a Valued Behaviours Assessment and it is quite important: our team won’t be able to see your application until you pass this assessment. Feel free to contact us at CoreStratsRoles(a)sc.com if you have any questions about these positions.

1 0

Two mysteries
by Henry Laxen 28 Aug '22

28 Aug '22

-- run this with ghci -package microlens-platform -package stm -package containers SC.hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TemplateHaskell #-} module Games.SC where import qualified Data.Map.Strict as M import GHC.IO.Unsafe ( unsafePerformIO ) import Lens.Micro.Platform import Control.Concurrent.STM.TVar import Control.Concurrent.STM import Control.Monad.IO.Class type Lenstype f a b = (b -> f b) -> a -> f a instance Show a => Show (TVar a) where show x = unsafePerformIO $ do sx <- readTVarIO x return ("TVar: " <> show sx) newtype TMap k v = TMap (TVar (M.Map k (TVar v))) deriving Show -- TMap (TVar (Map k (TVar v))) -- ^^^^ modify this TVar to add/delete a key -- TMap (TVar (Map k (TVar v))) -- ^^^^ modify this TVar to change a value withKey :: (MonadIO m, Ord k) => k -> (Maybe v -> v) -> TMap k v -> m () withKey k f (TMap x) = liftIO $ do atomically $ do tMap <- readTVar x let mbK = M.lookup k tMap case mbK of -- insert a new (key,value) into the map Nothing -> do v' <- newTVar (f Nothing) let newMap = M.insert k v' tMap writeTVar x newMap Just tv -> do -- modify the value of an existing key v' <- readTVar tv let newV = f (Just v') writeTVar tv newV return () class State a where type StateKey a :: * type StateValue a :: * lensTmap :: Functor f => Lenstype f a (TMap (StateKey a) (StateValue a)) lensKey :: Functor f => Lenstype f a (StateKey a) lensCounter :: Functor f => Lenstype f (StateValue a) Int updateState state f = liftIO $ do let key = state ^. lensKey -- read the key mutable = state ^. lensTmap -- find the TVar of the TMap withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it -- THE FIRST MYSTERY: If I use the inferred type explicitly for updateState -- above, this no longer compiles. I get a "could not deduce" error -- reproduced below: -- xupdateState -- :: (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) => -- s -> (Int -> Int) -> m () -- xupdateState state f = liftIO $ do -- let -- key = state ^. lensKey -- read the key -- mutable = state ^. lensTmap -- find the TVar of the TMap -- withKey key (\(Just x) -> x & lensCounter %~ f) mutable -- update it -- /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:33-43: error: -- • Could not deduce: StateValue a0 ~ StateValue a -- from the context: (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) -- bound by the type signature for: -- xupdateState :: forall (m :: * -> *) s a. -- (MonadIO m, Ord (StateKey s), State s, State a, -- StateValue s ~ StateValue a) => -- s -> (Int -> Int) -> m () -- at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:(76,1)-(79,30) -- Expected type: ASetter (StateValue a) (StateValue a) Int Int -- Actual type: Lenstype -- Data.Functor.Identity.Identity (StateValue a0) Int -- NB: ‘StateValue’ is a non-injective type family -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ -- In the second argument of ‘(&)’, namely ‘lensCounter %~ f’ -- In the expression: x & lensCounter %~ f -- • Relevant bindings include -- x :: StateValue a -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:84:23) -- mutable :: TMap (StateKey s) (StateValue a) -- (bound at /home/henry/nadineloveshenry/projects/nlh/src/Games/SC.hs:83:5) data SampleState = SampleState { _key :: String , _tMap :: TMap String SampleValue } deriving Show data SampleValue = SampleValue { _counter :: Int , _other :: () } deriving Show $(makeLenses ''SampleState) $(makeLenses ''SampleValue) makeSampleState :: IO SampleState makeSampleState = do let sampleValue = SampleValue 1 () tvar1 <- newTVarIO sampleValue let sampleTMap = M.fromList [("a", tvar1)] tvar2 <- newTVarIO sampleTMap return (SampleState "a" (TMap tvar2)) -- I can show the result of makeSampleState: -- λ> makeSampleState -- SampleState {_key = "a", _tMap = TMap TVar: fromList [("a",TVar: SampleValue {_counter = 1, _other = ()})]} bump1 :: IO () bump1 = do xss <- makeSampleState let xTmap = xss ^. tMap withKey "a" (\(Just x) -> x & counter %~ (+1)) xTmap print xTmap -- Everything here is tickety-boo -- λ> bump1 -- TMap TVar: fromList [("a",TVar: SampleValue {_counter = 2, _other = ()})] -- Now let's make SampleState an instance of State instance State SampleState where type StateKey SampleState = String type StateValue SampleState = SampleValue lensTmap = tMap lensKey = key lensCounter = counter -- THE SECOND MYSTERY: now lets try bump1 with the type family, but there is no joy -- bump2 :: IO () -- bump2 = do -- xss <- makeSampleState -- let xTmap = xss ^. lensTmap -- withKey "a" (\(Just x) -> x & lensCounter %~ (+1)) xTmap -- print xTmap -- SC.hs:163:33-43: error: -- • Couldn't match type ‘StateValue a0’ with ‘SampleValue’ -- Expected type: ASetter SampleValue SampleValue Int Int -- Actual type: Lenstype -- Data.Functor.Identity.Identity (StateValue a0) Int -- The type variable ‘a0’ is ambiguous -- • In the first argument of ‘(%~)’, namely ‘lensCounter’ -- In the second argument of ‘(&)’, namely ‘lensCounter %~ (+ 1)’ -- In the expression: x & lensCounter %~ (+ 1) -- Can someone please explain what is going on, or point me at a book/paper -- Thanks in advance. -- You can load this into ghci and uncomment to "bad" code to see for -- yourself what happens -- Nadine and Henry Laxen The rest is silence Gral. Manuel Márquez de León 1301 Onix #2302 Zona Urban Rio Never try to teach a pig to sing; Tijuana It wastes your time +52 (333) 667-8633 And it annoys the pig

3 3

[ANN] gitlab-haskell 1.0.0.1
by Rob Stewart 23 Aug '22

23 Aug '22

Hi, I'm pleased to announce the release of gitlab-haskell-1.0.0.1 . This library lifts the GitLab web API into Haskell. The library also has an event driven API for implementing server-side GitLab file hooks. This 1.0.0.1 release features: 1. Complete coverage of the GitLab v4 REST API. 2. An extensive suite of unit tests for parsing and serialising GitLab JSON objects. Documentation: https://hackage.haskell.org/package/gitlab-haskell Repository: https://gitlab.com/robstewart57/gitlab-haskell Details of the real-time API for GitLab events: https://www.macs.hw.ac.uk/~rs46/posts/2020-06-06-gitlab-system-hooks.html -- Rob Stewart https://www.macs.hw.ac.uk/~rs46/

1 0

Munich Haskell Meeting, 2022-08-25 @ 19:30
by Leah Neukirchen 22 Aug '22

22 Aug '22

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, August 25 at *Hofbräukeller am Wiener Platz* 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 look out for you: https://nuudel.digitalcourage.de/haskell-munich-aug-2022 (dudle is broken today, so we use nuudel instead.) Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

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

22 Aug '22

The GHC developers are happy to announce the availability of GHC 9.4.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.2 This release is primarily a bugfix release addressing a few packaging issues found in 9.4.1. See the [release notes] for a full accounting. Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new 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 also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. 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 Haskelling, - Ben [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.2/docs/users_guide/9.4.2-notes.html [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

1 0

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