- Haskell-Cafe - Haskell.org

[ANN] Cabal-3.6.1.0 and cabal-install-3.6.0.0
by Emily Pillmore 10 Sep '21

10 Sep '21

Hello all, The Cabal team is excited to announce the release of both `Cabal-3.6.1.0`, and `cabal-install-3.6.0.0`! ## Changelog for `Cabal-3.6.1.0` This release of `Cabal` is a point release that allowed us to get some important features out into the ecosystem that just couldn't wait: - Include cmm-sources when linking shared objects - Prefer canonicalized path when guessing tools from GHC path - Fix `cabal test --enable-library-coverage` for modules in the `other-modules` field - set the PATH_SEPARATOR value to `;` when calling `./configure` on Windows (this is necessary for autoconf >=2.7) - Significant speedups to the solver ## Changelog for `cabal-install-3.6.0.0` This is the fourth release of the 3.0 release series for `cabal-install`, introducing features and quality of life improvements including: - Better support for `hsc2hs`, allowing users to pass additional options - Added an `--only-download` flag - extra-packages now works properly - `cabal init` UX improvements - GHC 9.2 support - Fixes to the backpack UX - Removing the spurious warnings for extraneous versions on internal packages - Alerts and spelling suggestions for mispelled comands - Massive improvements to code organization and repository health For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.…. If you have issues, we'd love to hear about them here: https://github.com/haskell/cabal/issues. ## Plans for 3.8 The 3.6 release marks the first in a series where we work to modernize the Cabal project by means of doing away with the idiosyncratic and historical cruft built up, improving the contribution experience. Over the next 6 months, we'll be working hard to improve the state of the repository, including onboarding more maintainers and welcoming new contributors with clearer contribution requirements. To start, we've identified issues and new features that we aim to tackle for the 3.8 release spanning the following: - Better build info for tool creators - Support for stable package sets like LTS - Dropping build/test support for GHCs outside of the 5 year window - Finishing the multilib work - a byte-for-byte bidirectional parser - etc. You can find the full list of 3.8 project issues here: https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+project%3Aha…. I'd also like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! And a special thank you to the Haskell Language Server team for working with us and the Haskell Foundation to help fund work needed to improve the IDE. Happy hacking! Emily

2 1

Using a non fully saturated type family
by Ruben Astudillo 09 Sep '21

09 Sep '21

Hello Cafe. I am trying to encode a version of sigma types using GADTs for the tag and a type family as the function between the GADT and the universe of types. My code looks like this (notice the use of StandaloneKindSignatures). --- | dependent.hs {-# language RankNTypes, PolyKinds, TypeFamilies, GADTs #-} {-# language StandaloneKindSignatures, DataKinds #-} module Main where import Data.Kind (Type) import Data.Functor.Identity main :: IO () main = return () type Tag :: Bool -> Type data Tag b where STrue :: Tag True SFalse :: Tag False type ApplyTag :: Bool -> Type type family ApplyTag t where ApplyTag 'True = Int ApplyTag 'False = Char type Sigma :: forall k. (k -> Type) -> (k -> Type) -> Type data Sigma t f where (:&:) :: forall t f a. t a -> f a -> Sigma t f ex :: Sigma Tag ApplyTag ex = STrue :&: 27 The error I get is dependent.hs:24:7: error: • The type family ‘ApplyTag’ should have 1 argument, but has been given none • In the type signature: ex :: Sigma Tag ApplyTag | 24 | ex :: Sigma Tag ApplyTag | ^^^^^^^^^^^^^^^^^^ which is true! How can I recover the intuition of type families being functions at the type level? -- Rubén. (pgp: 4EE9 28F7 932E F4AD)

3 3

Type synonym involing quantified constraint?
by Michael Sperber 07 Sep '21

07 Sep '21

I'm working on Conal's ConCat code, and keep putting quantified constraints like this in instance constraints: (okk ~ Ok k, forall x y. (okk x, okk y) => okk (Prod k x y)) (The okk ~ Ok k is necessary because Ok is an associated type.) Is there any way to define a type synonym for this? Like type OkProd k = (okk ~ Ok k, forall x y. (okk x, okk y) => okk (Prod k x y)) ghc (8.10.4) complains about an impredicative type. Help would be much appreciated! -- Regards, Mike

2 4

Re: [Haskell-cafe] broadcasting stateful computations
by Olaf Klinke 06 Sep '21

06 Sep '21

Thanks everyone for the helpful suggestions! Bryan Richer wrote: > what if the TVar is part of the > state s? > (StateT IO) can't give any guarantees about when or how the state is > broadcast, but using STM within StateT actions still can. I don't understand this, but it may go into the same direction as: Chris Smith wrote: > I had the same suggestion. However, you then no longer need StateT, as > ReaderT is enough. Using a `ReaderT (TVar s) IO a` will allow atomic > changes to the state s, along with interleaved IO when it's done safely > rather than in the middle of a transaction. ReaderT (TVar s) IO is interesting! It does not solve the problem of atomic modifications with side-effects, though. Currently I am implicity using ReaderT (TVar s), by explicitly passing the TVar around. In principle, for atomic modifications I have to get hold of a pure version (s -> s) of the modification. Maybe within a monadic context. But if determining this modification function is side-effectful, then it can not depend on the initial contents of the TVar! This leads me to the conclusion that either (a) atomic modification by a Kleisli map is impossible and another mechanism needs to ensure thread safety, or (b) we need to keep two versions of the state: one private, pure s and one public TVar s which we synchronize from time to time. The latter can be accomplished with atomic writes. More on that below. Isaac Elliott wrote: > What about creating a MonadState instance for the TVar? Very neat, but it would not solve the atomicity problem, since the update I have is not expressible as stateTVar. YueCompl wrote: > I believe this is the use case for TMVar, use `takeTMVar` / `putTMVar` instead of `readTVar` / `writeTVar` will do. TMVars appear non-empty for one thread only, as far as I understand. So any observer thread would be blocked while the worker thread is updating the state? Not good for my use case. The observer thread will be a webserver. I'd rather have the webserver report old states than block. I have neglected to mention one aspect of my problem that might be essential: All my state updates are monoidal. By that I mean that s is a monoid with s' <> s <> s = s' <> s and any effectful modification will be of the form f = \s -> (k s) >>= (\s' -> s' <> s) for some k :: s -> m s. This entails that instead of emitting modifications as functions I can emit modifications as values. emitModification :: (Monad m, Monoid s) => StateT s m a -> WriterT s (StateT s m) a emitModification (StateT f) = WriterT $ StateT $ \s -> do (a,s') <- f s return ((a,s'),s') broadcastModification :: (MonadIO m, Semigroup s) => TVar s -> (WriterT s m) a -> m a broadcastModification ref (WriterT m) = do (a,s') <- m (liftIO.atomically) (modifyTVar ref (\s -> s' <> s)) return a Then \ref -> broadcastModification ref . emitModification :: (MonadIO m, Monoid s) => TVar s -> StateT s m a -> StateT s m a This has the additional charm that I can explicitly control when writes to the TVar happen, by choosing which (StateT s m) blocks to enclose in this wrapper. I might even set up my communication as a TChan, if the observing thread maintains an own copy of state itself to merge the updates s' into. Olaf

3 9

New package: lazify
by David Feuer 03 Sep '21

03 Sep '21

Occasionally, it's useful to make things lazier. The utility-ht package has long offered forcePair :: (a,b) -> (a,b) forcePair ~(a,b) = (a,b) But that only works for pairs! If you want to work with records/tuples much more generally, now you can do so conveniently with the lazify package. Please take a look and let me know what you like and dislike, and whether there's anything more you want. https://hackage.haskell.org/package/lazify-0.1.0.1

2 2

broadcasting stateful computations
by Olaf Klinke 02 Sep '21

02 Sep '21

Dear Café, I have a sequence of state-modifying computations action :: MonadUnliftIO m => StateT s m () where the state s should be visible to other threads. Thus I created a TVar in which I keep track of this state s for other threads to read. The type system tells me it can't be done, which suggests I am using the wrong abstraction. The following type-checks but may be unsafe. import Control.Concurrent.STM import Control.Monad.IO.Unlift updateStateTVar :: MonadUnliftIO m => TVar s -> StateT s m () -> m () updateStateTVar var action = withRunInIO (\inIO -> do s0 <- atomically (readTVar var) s1 <- inIO (execStateT action s0) atomically (writeTVar var s1)) Yet the splitting into readTVar and writeTVar is dangerous if several threads have read/write access to the same TVar. I was hoping to write the above using modifyTVar. However, the action essentially gives me a Kleisli map s -> m s which I somehow have to turn into an m (s -> s) but it is not possible in general. (The reverse works for any functor.) What should I do? * Switch to WriterT (Endo s) m? This is not as powerful as StateT s m. * Do everything in the STM monad? But this disallows arbitrary IO because it would facilitate nested STM transactions. The code above is safe, I believe, if only one thread has read/write access and the others are read-only. Are there type-level abstractions of this kind? (I suppose one could easily make them with some newtypes.) Thanks in advance for any thoughts on this. Olaf

5 4

[conference announcement] Haskell Love Conference 2021
by Ida Bzowska 31 Aug '21

31 Aug '21

Hi Haskellers, Kindly reminder: https://haskell.love is taking place in 10 days. The conference is free to attend, held online, with the best schedule you can imagine (talks by: Simon Peyton-Jones as a keynote, Chris Penner, Dmitrii Kovanikov, Gergő Érdi, Ivan Gromakovskii, Jan Christopher Vogt, Jeremy Gibbons, Marcin Szamotulski, Mikael Tönnberg, Noon van der Silk, Rebecca Skinner, Ryan Orendorff, Stephanie Weirich, Thomas Tuegel, Gershom Bazerman, Joseph Morag, Veronika Romashkina). If you don't have a good excuse to skip the event then grab your ticket! λCheers, Ida Bzowska

1 0

IFL'21 final call for participation
by Pieter Koopman 30 Aug '21

30 Aug '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> *Registration* *Registration is **free of charge, but required for participation!* We will mail the zoom link only to registered participants. Use the below link to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8of… <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> *Program* The program is now available at https://ifl21.cs.ru.nl/Program <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . *Scope* The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2021 will be 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 languages and function-based programming. *Organisation* IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands *PC* Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary [image: beacon]

1 0

Take-over request for: blaze-textual
by Andrey Prokopenko 30 Aug '21

30 Aug '21

Hello, - Few months ago I opened PR in `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 <https://github.com/bos/blaze-textual/pull/14> - The package is either direct or transient dependency for `haskell-language-server`, `sqlite-simple` and few more packages. - While forks maintenance is a well-known practice it creates burden on maintainers. I would like to become a maintainer for `blaze-textual` package and keep it up-to-date at least for a next few years. Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package <https://wiki.haskell.org/Taking_over_a_package> Best Regards, Andrey Prokopenko

2 5

Remove 'show-build-info' from lib:Cabal
by Fendor 30 Aug '21

30 Aug '21

Hello everyone! The lib:Cabal (Setup.hs) command 'show-build-info' is going to be removed with the next Cabal version (3.8). It is being replaced by the build flag '--enable-build-info' that is added to 'build' directly. If you depend on 'show-build-info' in any way, please give us feedback on [1] or [2]. Details on the purpose and implementation of 'show-build-info' can be found here: [1] Best regards, Fendor [1]: https://github.com/haskell/cabal/issues/7489 [2]: https://github.com/haskell/cabal/pull/7498

1 0