May 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

Re: [Haskell-cafe] How to do reversible parsing?
by Johannes Waldmann 10 Jul '21

10 Jul '21

Rendell and Ostermann, Invertible syntax descriptions, Haskell Symposium '10 https://doi.org/10.1145/1863523.1863525 https://hackage.haskell.org/package/invertible-syntax For the general background, see, e.g., Grohne and Voigtländer 2017 Formalizing semantic bidirectionalization ... https://doi.org/10.1016/j.jlamp.2016.04.002 And there's a workshop series on Bidirectional Transformations (from 2012 onwards) - J.

3 9

Could optimize attoparsec if GHC would collapse `runParser (Parser parser)` to `parser`
by Tyson Whitehead 11 Jun '21

11 Jun '21

Hi. I'm hoping someone with some knowledge about GHC optimizations can weigh in and help out here. The attoparsec library has a `<|>` combinator for choice. Since attoparsec does arbitrary backtracking, you would expect that `recursiveLhs <|> rhs` would stack up a bunch of `rhs` alternatives to the depth of the recursion. Looking at the definitions though, would make you believe that so long as the `rhs` is constant as it usually is (e.g., `pure []` if you are collecting a list), inlining should result in it not stacking up a bunch of the `rhs` alternatives (intuitively the most recent one will always succeed so there is no reason to hold on to more than one). Unfortunately, it doesn't seem to work. The full details can be found in this bug report https://github.com/haskell/attoparsec/issues/186 but I believe it comes down to the fact that GHC is not collapsing a packing and immediate unpacking of the parser datatype ``` runParser (Parser parser) -> parser ``` which is resulting in the fact that the `rhs` always succeeds (i.e., doesn't use the failure continuation) not being exposed. I am hoping someone knowledgeable in these matters could weigh in. Thanks! -Tyson PS: The parser datatype is a wrapper on CPS style lambda ``` newtype Parser i a = Parser { runParser :: forall r. State i -> Pos -> More -> Failure i (State i) r -> Success i (State i) a r -> IResult i r } ``` where Failure and Success are type synonyms for the continuations ``` type Failure i t r = t -> Pos -> More -> [String] -> String -> IResult i r type Success i t a r = t -> Pos -> More -> a -> IResult i r ```

2 1

Generic Traversal of ASTs
by Richard Yu 02 Jun '21

02 Jun '21

I have a question about generic traversal/transformation of nested data structures. From what I understand the main options available are SYB, Uniplate, GHC.Generics and Data.Lens (although I am under the impression this requires record types). The data structure I am attempting to traverse is similar to this simplified version: data SExpr = Expr | Const data Const = B bool | I int data Expr = Lambda String SExpr | If Expr ... I have attempted to use Uniplate and GHC.Generics to traverse the built AST and modify for example, the string of a Lambda type, but have not been able to figure out how to get any of the libraries to typecheck. The examples or docs I found were not quite enough. Does anyone know of examples that might help or explain how I should be using the generic libraries? In addition if I moved to writing the AST with GADTs, do some generic traversal strategies/libraries stop working? Many thanks, Richard

4 4

Wrapping external process communication in a nice API?
by Mario Lang 31 May '21

31 May '21

Hi. For my chessIO package, I wrote a module to communicate with UCI (Universal Chess Interface) speaking chess engines. This sort of thing is pretty new to me. I settled to use attoparsec for parsing and TChan to feed incoming data to the library users. This is the first thing that I found which looked like it could work... I would be thrilled if someone with more experience in this area would give my approach a review. Let me know if something is glaringly unidiomatic, I am sure you will find things. https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs This is for me to learn, and to avoid putting weird stuff on hackage... I actually prefer private mail, but a GitHub issue or even a PR are also highly welcome. Thanks. -- CYa, ⡍⠁⠗⠊⠕

4 9

bottom/unconditionally false in Haskell
by Galaxy Being 31 May '21

31 May '21

I just ran into this formula head = foldr (<<) ⊥ where x << y = x in Bird and Gibbons' *Algorithm Design with Haskell* and I understand it's a sort of pseudo-code. Intuitively, I understand that foldr will take "bottom" as its "starter seed", but I don't know how to convert the << into Haskell code. This works myHead = foldr choose1st undefined where choose1st x y = x but I can't get myHead2 = foldr (<<) undefined where << x y = x to work. How do you create a non-alphanumeric operator like <<? -- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

3 2

Is there some tool for inferring wide dependency ranges?
by Askar Safin 30 May '21

30 May '21

Hi. Is there some tool for inferring dependency ranges for my cabal packages? I know about "cabal gen-bounds", but this command gives too short ranges. I want to get as wide range as possible. I. e. I want tool, which tries to build and test my package on various versions of dependencies, and reports resulting range. Successful testing should mean that the version of dependency is compatible. That tool should work also on "base" package, this means that it should test various ghc versions, too. If there is no such tool, then at least I want some tool, which will check already specified dependency range. Such tool should do this: - Extract dependencies from cabal file - Install smallest versions of specified dependencies (this will include "base" and thus ghc) - Test on this versions - Install largest versions - Test on this versions I will put invocation of such tool to continuous integration. I hope there are a lot of package maintainers here. How do you manage dependencies? == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar

3 6

Request for Haskell wiki editing account
by Michael Turner 30 May '21

30 May '21

I've been a contributor to Wikipedia for a long time https://en.wikipedia.org/wiki/Special:Contributions/Yakushima and I'm a Haskell newbie. As I run across problems in getting started, I'd like to improve the Haskell wiki so that others can avoid similar problems. Requested username for Haskell Wiki: Yakushima Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

2 3

ML Family Workshop 2021: deadline extension
by Jonathan Protzenko 28 May '21

28 May '21

The deadline for the ML family workshop has been extended by a week. If you were on the fence, please submit! --- We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021. The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas. ## Submission details Submissions must be at most three pages long; see the full call for papers <https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#Call-for-Presentations> for details. Submission site: https://ml21.hotcrp.com/ ## Important dates Thu, Jun 3th 2021 (AoE): submission deadline Thu, Jun 24th 2021 (AoE): author notification Thu, Aug 26th: workshop (time slots TBD) ## Program committee Danel Ahman (University of Ljubljana) Robert Atkey (University of Strathclyde) Frédéric Bour (Tarides) Ezgi Çiçek (Facebook London) Youyou Cong (Tokyo Institute of Technology) Richard A. Eisenberg (Tweag I/O) Martin Elsman (University of Copenhagen, Denmark) Ohad Kammar (University of Edinburgh) Naoki Kobayashi (University of Tokyo, Japan) Benoît Montagu (Inria) Jonathan Protzenko (Microsoft Research) (Chair) Kristina Sojakova (INRIA Paris) Don Syme (Microsoft) Matías Toro (University of Chile) Katsuhiro Ueno (Tohoku University)

1 0