August 2021 - Haskell-Cafe

Some Love for wxHaskell
by Tilmann 30 Jan '22

30 Jan '22

Hi cafe, I think wxHaskell needs some love :) Over the years I've written a small client for FICS (Free Internet Chess Server) and wxHaskell has served me really well. Also, wxWidgets seems solid and alive.. but today, wxHaskell is lagging behind updates and seems *sniff* dead. Is someone working on wxHaskell atm? I'd love to connect and help. If not, is there some interest to rejuvenate wxHaskell? Who is also depending on wxHaskell and wants to keep it going? Or, is it time to move on to gtk or reflex? Very much looking forward to your replies! Best, Tilmann

3 4

Do something about Cabal?
by Ignat Insarov 03 Jan '22

03 Jan '22

# Do something about Cabal? Hello. Cabal is the second most used tool in Haskell after GHC. It has many problems. It may be noticed that there is one and a half developers working on it. This is clearly not enough to address these problems. I propose that this is a good place to invest in. ### Problems I have in mind: * Poor communication, lack of open source development process. The whole Cabal–Stack schism appears to be an outcome of poor communication. One of the leading developers of Cabal is even banned from participation somewhere in Stack circles.[1] Personally, I reported several issues to Cabal and every single time it resulted in sadness. Observe a vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒ there are fewer contributors ⇒ core developers are overworked. I have no hard evidence but it appears that presently, more people that strive to improve the Haskell build experience are outside the Cabal cabal than are inside. * User experience is an afterthought. Cabal's user experience is horrifying. A collection of complaints is being compiled elsewhere.[2] There are also bugs being opened to Cabal because of this, requiring triage and therefore wasting the precious time of the few overworked developers. Stack is much more friendly — this shows by example that the user experience problem is not inherent and may be solved. It is ordinary to receive output like this: ``` % cabal run example-executable Warning: The package list for 'hackage.haskell.org' is 84 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: example-0.1.0.6 (user goal) [__1] next goal: opaleye (dependency of example) [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project config TODO requires ==0.6.7006.1) [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7) [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2, opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1, opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0, opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0, opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0, opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3, opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0, opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the previous version to fail: excluded by constraint '^>=0.7' from example) [__1] fail (backjumping, conflict set: example, opaleye) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: opaleye, example ``` There are so many things that are wrong here. Even a sneaky _«to do»_ remark. If you wonder, in this case the solution is to remove and re-generate `cabal.project.freeze`. Even the name of the program — it is actually _«cabal-install»_ — is incomprehensible, it should be re-branded to Cabal, which is how everyone calls it anyway. * Features are not being introduced. There is no reason for two build tools to exist. The killer feature of Stack — snapshots — should be supported by Cabal. Possibly Cabal itself should be refactored and split so that there are separate tools for packaging, version resolution and human interaction — I do not know. But certainly the way things are presently is a waste of developer effort and a source of confusion for everyone. ### My proposition, in particular. * Ask all the people that show compassion to the cause of a great Haskell build tool to unite and work together on a better Cabal. This includes the developers of Stack and everyone that expressed unhappiness with the current state of Cabal. These people should be seen as a blessing, not as an obstacle. * Put in place a clear process for contributing and decision making, so that it does not come down to the privileged opinion of one of the core developers. * Make a model of user experience that Cabal should conform to, and make conformance a priority. Surely there are among us people that know a thing or two about user experience — call for them to step forward. Every issue that stems from misunderstanding, re-assign to the model instead of closing. * Merge the support of Stackage snapshots into Cabal. Ask the core developers of Stack to join the effort. Transition from Stack to Cabal should be one well discoverable command that just works. I realize that this letter is largely an opinion piece. You can also see it as an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the present. I do not insist that my vision is the best. But the present reality is not the best vision either. I propose, foremost, that we work and fight for a better future. [1]: https://github.com/commercialhaskell/stackage/issues/4472 [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal

23 39

Examples of Continuation monad that impossible to understand and maintain?
by YueCompl 08 Oct '21

08 Oct '21

Dear Cafe, I'm wrapping up my CPS codebase to provide some monadic interface, it appears almost the Cont monad, so the following statement is a pretty valid caveat to me now: > Abuse of the Continuation monad can produce code that is impossible to understand and maintain. Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… <https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… of the Continuation monad can produce code that is impossible to understand and maintain> But I can't find concrete examples demonstrating the "impossible to understand and maintain" situation, in figuring out what pitfalls I'd rather to avoid. Please share what you know about it, many appreciations! Background of my CPS necessarity: Library code need to delegate STM transaction boundary delimitation to (scripting) application code, though `inlineSTM :: STM a -> m a` can be used to force some action to be within current tx, the usual `>>=` binding should honor whether a separate `atomically` tx should be issued for its rhs computation, as specified by the scripting context. Thanks, Compl

4 8

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

[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

Re: [Haskell-cafe] Contents of Haskell-Cafe digest...
by Kim Chaegon 29 Aug '21

29 Aug '21

Hello! I want read and learn continually haskell for mathematics. Please send me your text about haskell. Thank you!

1 0

[Call for reviewers] Switch `text`'s internal representation to UTF-8
by Hécate 27 Aug '21

27 Aug '21

Hello everyone, After tremendous efforts, the pull request to switch `text`'s internal representation to UTF-8 is here, and unsurprisingly this is a titan's work. It lives here: https://github.com/haskell/text/pull/365 We are sending out a call for reviewers, as this is a cornerstone of our ecosystem. The performance gains from this PR are huge and I would like to ensure we can have a multitude of eyes to take a look. I wish to express my thanks to all of you. This is definitely the kind of advances that will make Haskell a stronger language for the times to come. Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0