April 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

Safe Haskell?
by Richard Eisenberg 04 May '21

04 May '21

Hi café, Do you use Safe Haskell? Do you know someone who does? If you do, which of Safe Haskell's guarantees do you rely on? Here, a user of Safe Haskell is someone who relies on any guarantees that Safe Haskell provides, not someone who makes sure to have the right pragmas, etc., in your library so that users can import it Safely. Context: Safe Haskell is not lightweight to support within GHC and the ecosystem. Despite being a formidable research project with a (in my opinion) quite worthwhile goal, it's unclear which of Safe Haskell's purported guarantees are actually guaranteed by GHC. (The lack of unsafeCoerce is not actually guaranteed: https://gitlab.haskell.org/ghc/ghc/-/issues/9562 <https://gitlab.haskell.org/ghc/ghc/-/issues/9562>.) Recent design questions about what should be Safe and what shouldn't be (somehow cannot find the discussion after a few minutes of searching; perhaps fill this in) have been answered only by stabs in the dark. The status quo is causing pain: https://gitlab.haskell.org/ghc/ghc/-/issues/19590 <https://gitlab.haskell.org/ghc/ghc/-/issues/19590>. There are hundreds (maybe thousands) of lines of delicate logic within GHC to support Safe Haskell. These parts of GHC have to be read, understood, and maintained by people with limited time. I thus wonder about deprecating and eventually removing Safe Haskell. I don't have a concrete plan for how to do this yet, but I'm confident we could come up with a migration strategy. The set of people who would win by removing Safe Haskell is easy enough to discover. But this email is intended to discover who would be harmed by doing so. If you know, speak up. Otherwise, I expect I will write up a GHC proposal to remove the feature. Thanks, Richard

18 41

Free online intro/advanced Haskell courses [YouTube]
by Graham Hutton 01 May '21

01 May '21

Hi all, For the last few months, I've been preparing YouTube videos for the introductory and advanced Haskell courses that I teach to students at the University of Nottingham. The courses have now finished, and the full sets of videos are now available: Intro course: http://www.tinyurl.com/haskell-notts Advanced course: http://www.tinyurl.com/haskell-notts2 There’s also a 25% discount for the textbook on which both of the courses are based, Programming in Haskell: Discount link: http://tinyurl.com/25pct-off Best wishes, Graham — Professor Graham Hutton School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~pszgmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

3 2

ANN: second release candidate for stack-2.7
by Emanuel Borsboom 30 Apr '21

30 Apr '21

You can download binaries for this pre-release from https://github.com/commercialhaskell/stack/releases/tag/rc%2Fv2.7.0.3 Please test it and let us know if you run into any trouble. If all goes well, we expect to release the final version in X weeks. Release notes: * Stack's bindists are now built with GHC 8.10.4, and our `stack.yaml` has moved to lts-17.10. This means Stack can now be built on macOS 11.0 (Big Sur) without ugly workarounds. GHC 8.8 is now the minimum GHC version supported for building Stack itself (but this does not effect _users_ of Stack, which still supports using much older GHC versions). **Changes since v2.7.0.1:** (no changes)

1 0

[ANNOUNCE] Experimental Windows GHC 8.10.5 binary release. Supports Haskell DLLs.
by kyra 29 Apr '21

29 Apr '21

An experimental Windows GHC 8.10.5 64-bit Visual C/Native Windows SDK binary compatible distribution is released. Features: Supports Haskell DLLs. Both static and dynamic compilers are shipped. Uses LLVM tools exclusively, hence linking is blazing fast compared to the stock distro. Is position-independent (can be loaded to any address, not only the lower 2GBs) and generates position-independent code. Based on and targets Microsoft Visual C runtime and native Windows SDK. The "full" variant of distro contains 438 extra prebuilt packages and a set utilities, including not only the mandatory cabal, stack, Happy and Alex, but also linters, formatters, preprocessors, and even beasts like pandoc, haskell-language-server and even Agda compiler. Distribution site: https://awson.github.io/ghc-nw/. Cheers, K. Briantsev (aka awson)

1 0

Munich Virtual Haskell Meeting, 2021-04-29 @ 19:30
by Leah Neukirchen 28 Apr '21

28 Apr '21

Dear all, This week, our monthly Munich Haskell Meeting will take place again tomorrow(!) Thursday, April 29 on Google Meet at 19:30 CEST. **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Google Meet link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Template Haskell question
by Kai-Oliver Prott 28 Apr '21

28 Apr '21

Dear Cafe, what is the reasoning behind the behavior of the following two Haskell expressions: ghci> :set -XTemplateHaskell ghci> let f x ($([p| x |])) = x in f 1 2 2 ghci> let f ($([p| x |])) x = x in f 1 2 2 I'd have guessed that they should both fail compilation with "Conflicting definitions for ‘x’" like the following expression. ghci> let f x x = x in f 1 2 error: ... Moreover, it seems odd that the "x" on the right side always refers to the rightmost pattern variable "x" (regardless if quoted or not). Cheers, Kai

5 5

Haskell translation and transformation
by Dušan Kolář 27 Apr '21

27 Apr '21

Dear Café, I've tried to make my code more compact and faster in runtime and I tried to use primitive types, e.g. Int#. To omit all influences, I ended with Ackermann function: acker :: Int# -> Int# -> Int# acker 0# n = n +# 1# acker m 0# = acker (m -# 1#) 1# acker m n = acker (m -# 1#) (acker m (n -# 1#)) I was quite surprised, that the result was the same as for function without primitive types when it was compiled with -XStrict option. Both memory and time consumption was the same (small difference under 0.5%). Of course, -O2 option was used. :-) I compared with the same C implementation: int acker(int m, int n) { if (m==0) return n+1; if (n==0) return acker(m-1, 1); return acker(m-1, acker(m,n-1)); } with -O2 option used for gcc, the C code is 7 times faster, for no -O options provided both for ghc and gcc, the C code is also 7 times faster. Thus, no difference. My question is: does the ghc use primitive types automatically when possible? Otherwise, I cannot explain the same times... Or, to my big surprise, using primitives does not save memory and computation time, really? And the other question is about reasoning during translation and code generation, what is the reason the code is so slow? I would guess that forcing primitive types and strict evaluation would produce a code with comparable time to C code... The difference seems to be like the one between compiled code to executable and to low level virtual machine code, which is interpreted then. Versions I used: ghc: 8.10.3 gcc: 10.2.0 Dušan P.S. I definitely don't want to make someone upset with the content, I'm simply wondering... D.

2 1