- Haskell-Cafe - Haskell.org

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

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