- Haskell-Cafe - Haskell.org

Package takeover request for fgl
by Troels Henriksen 31 Aug '22

31 Aug '22

I am requesting to take over the package fgl: https://hackage.haskell.org/package/fgl It is currently broken in GHC 9.4, which is fixed by this pull request: https://github.com/haskell/fgl/pull/104 The maintainer Ivan Miljenovic has not been active on GitHub since January. I wrote Ivan on August 12th offering to help out with maintenance, but have received no response yet. The package is part of the 'haskell' organisation on GitHub. I don't know whether that is supposed to signify some kind of "community maintenance" (it appears Ivan is not the original author of fgl), but I would eventually need Hackage upload rights as well.

2 1

selectively allow alternatives in a sum type
by Olaf Klinke 31 Aug '22

31 Aug '22

Dear Café, Is there prior art/existing packages for the following? Is it maybefunctional programming folklore? Is it a sign of bad program design? Sometimes I feel the need to selectively allow or disallow alternatives in a sum type. That is, suppose we have a sum type data Foo = LeftFoo !A | RightFoo !B and at some places in the program we want the type system to enforce that only the constructor LeftFoo can be used. My solution would be to use a strict version of Data.Functor.Const and make the type higher rank: newtype Const' a b = Const' !a -- Const' Void b ~ Void -- Const' () b ~ () data Foo' f = LeftFoo' !A | RightFoo' !(f B) type Foo = Foo' Identity type LeftFoo = Foo' (Const' Void) -- can not construct a RightFoo' The advantage over defining LeftFoo as an entirely different type is that Foo and LeftFoo can share functions operating entirely on the left option. Olaf

6 6

With cabal.project, what's the story about warning and -Werror compiler flags?
by Nicolas Trangez 30 Aug '22

30 Aug '22

All, Working on some project, I was wondering about best-practices and community standards for compiler flags now that `cabal.project` is a thing. Before, I put compiler warning flags like `-Wall` in `Ghc-Options` and `Cc-Options` in `mypackage.cabal` files. The use of `-Werror`, whilst (IMHO) useful in development and CI was a bit more troublesome, since having those in `package.cabal` (not under a default-disabled flag) was frowned upon (and even not allowed by Hackage?) Having these options in `mypackage.cabal` always felt slightly weird, since they are in no way required for a package to function: they're developer options, not user/consumer options. Where `-wavx2` could be a required `Cc-Options` setting for a package to build/function, `-Wall` is not. With the advent of `cabal.project`, it seems to me this is the ideal place to put developer flags: from what I understood, `cabal.project` doesn't influence sdist/Hackage distribution, and hence could contain all kind of GHC and C compiler flags that are useful during development but not required for a package to build/function, including `-Werror` (if desired by the project authors). Does this sound like a reasonable stance? If it is, I did run into a couple of issues getting things to actually work. Whilst putting `Ghc-Options` in a `Package mypackage` section in `cabal.project` seems to work, I'm unable to achieve the same resulsts for C compiler invocations. Presumably there's a `Gcc-Options` setting one can use (which is also generated in `cabal.project.local` by `cabal configure --gcc-options ...`). However, in testing, it appears said compiler optons are only passed to GCC when compiling, e.g., a HSC2HS file, but not when compiling a C file part of a `C-Sources` setting (whilst `Cc-Options` in `mypackage.cabal` are). Is there some discrepancy between what can be done from `cabal.project` vs. `mypackage.cabal`? Is this intentional? Am I trying to accomplish something that isn't/shouldn't be supported by Cabal in the first place? Cheers, Nicolas

2 5

GHC Proposals session at Haskell Symposium at ICFP
by Joachim Breitner 30 Aug '22

30 Aug '22

Dear friends of GHC, this year’s Haskell Symposium will host a special “GHC Proposals session” where current, future and past GHC Proposals can be presented and discussed: https://icfp22.sigplan.org/home/haskellsymp-2022#GHC-Proposals-Session I invite all GHC Proposal authors (or otherwise interested party) who are in Ljubljana to present your ideas and plans; just e-mail me if you want a slot. I also invite everyone else – users, developers, educators – to join the session for the discussions of these proposals. Your chance to get your voice heard, and not just your writing on GitHub! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

[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 29 Aug '22

29 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 29 Aug '22

29 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 23 Aug '22

23 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 23 Aug '22

23 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