- Haskell-Cafe - Haskell.org

[ANN] Core Libraries Committee Elections
by Emily Pillmore 13 Sep '21

13 Sep '21

Dear Haskell Community, The Core Libraries Committee is seeking new members! As detailed in recent updates (see: https://discourse.haskell.org/t/state-of-the-core-libraries-committee-updat… ), we put out an internal call to discuss restructuring the CLC to better meet the needs of the community. In particular, we are in the planning stages of writing the new process, and are seeking **2** new members who, as part of their standard CLC duties, get to participate in its construction. ## Who should apply? Anyone who meets the following criteria should apply: 1. Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (2 to 3 per month), and *sustain* this for their term in a healthy manner. 2. Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the new Github-based CLC process on a semi-frequent basis (2 to 3 per month). 3. Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. 4. Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room - quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. This election is particularly special due to the fact that our new members will have the chance to help shape process for new generations of the CLC to come, and can take ownership from the ground up so to speak. This means that we can help shape a process that works better for us as modern Haskell developers, and help the CLC become a better fit for the community's needs. ## How can I apply? To apply for one of these positions, send an email to the CLC email address ( core-libraries-committee(a)haskell.org ) that consists of the following data: 1. The header "CLC Election September 2021 - <your name>" 2. Why you think you're a good fit given the above criteria 3. If applicable, please point us to some code you've written ## When will elections be decided? Please note the following dates: 1. Election submissions open: Sept 13 2. Election submissions close: Sept 20 3. Election outcome announced: Sept 27 Cheers, Emily - on behalf of the CLC

1 0

Comment on "The Historical Futurism of Haskell" by Andrew Boardman
by Dominik Schrempf 13 Sep '21

13 Sep '21

Hi! I am referring to the impressive talk/show/thought-provoking message about "The Historical Futurism of Haskell" delivered by Andrew Boardman at the Haskell Love Conference. I am not sure if I am allowed to link to the talk myself, since it is password protected, and was part of a conference. Maybe this can be done by the conference organizers, or by Andrew himself, if they please. In summary, and please add your comments or correct me, Andrew discusses that we truly believe that Haskell --- as a statically typed, lazy, pure, and functional language -- is an incredibly powerful tool, that should be made available to everybody now and for the next thirty years. However, he argues that this power is hard to access because we have a lot of "adequate" tooling for a fantastic language. He adds that we need superb tooling in order for "beginners to learn faster, and experienced programmers to accelerate productivity". He refers to overhauling programming environments to reflect data flow across and within functions and to "setting higher standards" for ourselves so that we finally "lift ourselves out of the pit of adequacy". He also asks whether it is really necessary to be in "crisis mode" to invest into fundamental changes of the ecosystem (escalation of commitment). I deeply agree, and wanted to thank Andrew for his talk. Personally, to me it seemed that Andrew was more referring to the programming environment than to the set of available libraries, although this may not have been his intention. I wanted to express that in my opinion, and in order to drive Haskell forward, we need a qualitative, reliable, performant, and well maintained "standard" library. Haskell has many "adequate" libraries but few superb ones. And while I understand that the immense advantages of being an open source community also come at a cost: a lot of work we do in our free time, because we have limited funding for improving libraries or development environments. Many libraries are maintained by one individual who may have the time and resources (or not) to look at standing issues or possibilities for improvements. In particular, I am a mathematician/statistician working in evolutionary biology. I work with multivariate distributions (hardly any of those are readily available on Hackage), I work with a lot of random numbers (the support for random sampling is mediocre, at best; 'splitmix' is standard by now but not supported by the most important statistics library of Haskell), I work with numerical optimization (I envy Pythonians for their libraries, although I still prefer Haskell because what I achieve, at least I get right), I work with Markov chains (yes, I had to write my own MCMC library in order to run proper Markov chains), I need to plot my data (there is no superb standard plotting library available in Haskell). By now, I do maintain library packages providing answers to some of these problems, but it was (and is) a lot of work. Finally, I want to thank all library developers for their impressive work, thank you! And still, I think it is not enough. In my opinion, these are all examples where Haskell needs to improve if we want to broaden the adoption among the general public. Do we have the resources? Thank you! Dominik

4 4

Virtual Haskell CoHack on Sep 25
by Chris Smith 12 Sep '21

12 Sep '21

For the second time, I'm hosting a virtual Haskell CoHack on September 25. If you've wanted to meet new Haskellers, give or hear lightning talks, and hack together on Haskell projects, this is your chance. Sign up at https://www.meetup.com/NY-Haskell/events/280727563/ The event will be held via Zoom. I've tried to time it to be reasonable for people across the Americas and Europe. Sadly, time zones cannot accommodate everyone. :( But if you can, please consider coming!

1 0

Backpack: polymorphic instantation?
by Jaro Reinders 12 Sep '21

12 Sep '21

I'm playing around with backpack, trying to rewrite existing libraries. My end goal is to see if Backpack could improve the primitive library. Right now, the primitive library (in my opinion) relies too heavily on specialization of its type classes, so I think Backpack could help. However, I seem to be running into a limitation. I am wondering if it is a fundamental limitation, if perhaps there is a workaround, or if Backpack could be improved to support this use-case. Instead of primitive, I will take the simpler example: semigroup, which also shows this limitation. Let's convert the Semigroup class to a backpack signature: unit indef where signature Semigroup where import Prelude hiding ((<>)) data T (<>) :: T -> T -> T The problem is how to implement this signature with the type of polymorphic lists. It is easy to implement it for concrete lists like strings: unit string where module Semigroup where import Prelude hiding ((<>)) type T = String (<>) :: T -> T -> T (<>) = (++) It is also possible to implement it in terms of another signature: unit list where signature Elem where data A module Semigroup where import Prelude hiding ((<>)) import Elem type T = [A] (<>) :: T -> T -> T (<>) = (++) This is still problematic, because it is annoying that this new type A needs to be instantiated each time you want to use it. However, even more importantly, if I want to translate the 'PrimMonad' class to a Backpack signature then the 'ST s' instance needs a polymorphic type variable 's', which cannot be made concrete. And do note that I want the monad to be concrete for performance reasons, but the 's' parameter doesn't have to be concrete, because it is a phantom parameter anyway. And for lists making the 'a' parameter concrete also would not improve performance as far as I know. One possible way to fix this is to add a type variable in the 'Semigroup' signature, but then I think it becomes impossible to write the 'String' instance and sometimes you need more than one new type variable such as with the 'ReaderT r (ST s)' instance of 'PrimMonad'. In OCaml you can still kind of work around this problem by creating local instances inside functions. That trick still allows you to write a polymorphic concatenation function using a monoid signature (taken from [1]): let concat (type a) xs = let module MU = MonoidUtils (ListMonoid(struct type t = a end)) in MU.concat xs;; So, I'm wondering if it would be possible to "generalise" over indefinite Backpack types such as 'A' in the 'Elem' signature above or if we can at least implement something which enables the same trick that you can use in OCaml. Thanks, Jaro [1] https://blog.shaynefletcher.org/2017/05/more-type-classes-in-ocaml.html

2 4

Re: [Haskell-cafe] Backpack: polymorphic instantation?
by Daniel Díaz 11 Sep '21

11 Sep '21

Perhaps this is not what you had in mind, but we could write a signature like {-# LANGUAGE KindSignatures #-} > signature Mystery where > import Data.Kind > import Control.Monad > data MysteryMonad :: Type -> Type > instance Functor MysteryMonad > instance Applicative MysteryMonad > instance Monad MysteryMonad > instance PrimMonad MysteryMonad that reused the existing PrimMonad class. Code could depend on that signature without being tied to a concrete monad (this would make the package that has the code "indefinite"). Once we compiled the indefinite code against an actual implementation, it would be optimized as if we had used concrete types from the beginning. One problem with this solution is that it leaves out ST. If we wanted to make it work with ST, one possible hack would be to define the signature like this data MysteryMonad :: Type -> Type -> Type > instance Functor (MysteryMonad s) > instance Applicative (MysteryMonad s) > instance Monad (MysteryMonad s) > instance PrimMonad (MysteryMonad s) And then use some kind of newtype adapter with a phantom type for non-ST monads: module Mystery where type MysteryMonad = W IO > newtype W m a b = W (m b) deriving newtype (Functor, Applicative, Monad) But perhaps it would complicate things too much. On Sat, Sep 11, 2021 at 2:08 PM <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Backpack: polymorphic instantation? (Jaro Reinders) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 11 Sep 2021 11:58:26 +0200 > From: Jaro Reinders <jaro.reinders(a)gmail.com> > To: Haskell Cafe <haskell-cafe(a)haskell.org> > Subject: [Haskell-cafe] Backpack: polymorphic instantation? > Message-ID: <3fb19986-f998-61c7-8c56-482b1647e2eb(a)gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > I'm playing around with backpack, trying to rewrite existing libraries. My > end > goal is to see if Backpack could improve the primitive library. Right now, > the > primitive library (in my opinion) relies too heavily on specialization of > its > type classes, so I think Backpack could help. However, I seem to be > running > into a limitation. I am wondering if it is a fundamental limitation, if > perhaps > there is a workaround, or if Backpack could be improved to support this > use-case. > > Instead of primitive, I will take the simpler example: semigroup, which > also > shows this limitation. Let's convert the Semigroup class to a backpack > signature: > > unit indef where > signature Semigroup where > import Prelude hiding ((<>)) > data T > (<>) :: T -> T -> T > > The problem is how to implement this signature with the type of > polymorphic > lists. It is easy to implement it for concrete lists like strings: > > unit string where > module Semigroup where > import Prelude hiding ((<>)) > type T = String > (<>) :: T -> T -> T > (<>) = (++) > > It is also possible to implement it in terms of another signature: > > unit list where > signature Elem where > data A > > module Semigroup where > import Prelude hiding ((<>)) > import Elem > type T = [A] > (<>) :: T -> T -> T > (<>) = (++) > > This is still problematic, because it is annoying that this new type A > needs to > be instantiated each time you want to use it. However, even more > importantly, > if I want to translate the 'PrimMonad' class to a Backpack signature then > the > 'ST s' instance needs a polymorphic type variable 's', which cannot be > made > concrete. > > And do note that I want the monad to be concrete for performance reasons, > but > the 's' parameter doesn't have to be concrete, because it is a phantom > parameter anyway. And for lists making the 'a' parameter concrete also > would > not improve performance as far as I know. > > One possible way to fix this is to add a type variable in the 'Semigroup' > signature, but then I think it becomes impossible to write the 'String' > instance and sometimes you need more than one new type variable such as > with > the 'ReaderT r (ST s)' instance of 'PrimMonad'. > > In OCaml you can still kind of work around this problem by creating local > instances inside functions. That trick still allows you to write a > polymorphic > concatenation function using a monoid signature (taken from [1]): > > let concat (type a) xs = > let module MU = MonoidUtils (ListMonoid(struct type t = a end)) in > MU.concat xs;; > > So, I'm wondering if it would be possible to "generalise" over indefinite > Backpack types such as 'A' in the 'Elem' signature above or if we can at > least > implement something which enables the same trick that you can use in OCaml. > > Thanks, > > Jaro > > [1] > https://blog.shaynefletcher.org/2017/05/more-type-classes-in-ocaml.html > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > ------------------------------ > > End of Haskell-Cafe Digest, Vol 217, Issue 10 > ********************************************* >

2 1

[ANN] vector-hashtables-0.1.0.1
by Andrey Prokopenko 10 Sep '21

10 Sep '21

Hello All, We would like to announce the release of yet another implementation of efficient mutable hashtables in Haskell. - It was created long time ago, GitHub: https://github.com/klapaucius/vector-hashtables <https://github.com/klapaucius/vector-hashtables>. - And it finally got its way to the Hackage: https://hackage.haskell.org/package/vector-hashtables <https://hackage.haskell.org/package/vector-hashtables>. - Benchmark report (HTML) could be also found via this link: https://an-pro.org/html/vhc.html <https://an-pro.org/html/vhc.html>. Best Regards, Andrey Prokopenko

1 0

[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