January 2022 - Haskell-Cafe

[CFP closing soon!] Functional Conf 2022 Call for Proposals close 15 Jan
by John Sinclair 11 Jan '22

11 Jan '22

Just 4 days remain to submit proposals for speaking at Functional Conf <https://signal2domain.online/click?redirect=https%3A%2F%2Fllink.to%2F%3Fu%3… Conf> 2022. This is an online opportunity for you to contribute to Asia’s most vibrant functional programming conference. All selected speakers get a free ticket to the conference. Share your knowledge of Haskell and connect with programmers actively contributing to the development of FP languages, developers using it in their day-to-day programming and those just getting started on their FP journey. There’s something for everyone! At our last conference we featured keynotes from international guests Edward Kmett <https://signal2domain.online/click?redirect=https%3A%2F%2Fllink.to%2F%3Fu%3… Kmett> (Chairman, Haskell Core Libraries Committee), Michael Snoyman <https://signal2domain.online/click?redirect=https%3A%2F%2Fllink.to%2F%3Fu%3… Snoyman> (VP Engineering at FP Complete) and Tony Morris <https://signal2domain.online/click?redirect=https%3A%2F%2Fllink.to%2F%3Fu%3… Morris> (Sr. Software Engineer at Queensland FP Lab). Will you join us as a speaker this year? This year we are focusing on the themes of: - Applying FP - Applying FP sessions are targeted at Developers, who understand the basics of FP, maybe even practice some FP at work. Helping them understand how they can apply even more FP concepts more at work. - FP Bootcamp - FP Bootcamp is targeted at Developers, who want to kick start their FP journey. - Mastering FP - Mastering FP sessions are targeted at Developers, who already apply a decent amount of FP concepts at work. Developers, who want to go deeper and maybe even become a contributor to a FP language or library. Session Formats - Talks/Case-Studies (20 or 45 minutes) - Demos (20 or 45 minutes) - Experience Reports (20 minutes) - Hands-on workshop/tutorials (45 or 90 minutes) Proposal submission deadline: 15 January Learn more and submit your proposal: https://confng.in/qXN4WvpA <https://signal2domain.online/click?redirect=https%3A%2F%2Fllink.to%2F%3Fu%3…>

1 0

strange link error
by PICCA Frederic-Emmanuel 10 Jan '22

10 Jan '22

Hello, I try to build a project which use C libraries. during the developpement I want to link directly with the work in progress libraries. So I added this in cabal. executable binoculars-ng [...] if flag(useHklDev) pkgconfig-depends: gobject-2.0 ghc-options: -pgml ghc-options: gcc ghc-options: "-optl-Wl,--allow-multiple-definition" ghc-options: "-optl-Wl,--whole-archive,../../hkl/.libs/libhkl.a,--no-whole-archive" ghc-options: "-optl-Wl,--whole-archive,../../binoculars/libhkl-binoculars.a,--no-whole-archive" at the end I have a working executable. Building executable 'binoculars-ng' for hkl-0.1.0.0.. [1 of 1] Compiling Main ( app/Binoculars.hs, /home/experiences/instrumentation/picca/src/repo.or.cz/hkl/contrib/haskell/dist-newstyle/build/x86_64-linux/ghc-8.8.4/hkl-0.1.0.0/x/binoculars-ng/build/binoculars-ng/binoculars-ng-tmp/Main.o ) Linking /home/experiences/instrumentation/picca/src/repo.or.cz/hkl/contrib/haskell/dist-newstyle/build/x86_64-linux/ghc-8.8.4/hkl-0.1.0.0/x/binoculars-ng/build/binoculars-ng/binoculars-ng ... But now I would like to create an unit test so I added this in cabal test-suite hkl-test [...] if flag(useHklDev) pkgconfig-depends: gobject-2.0 ghc-options: -pgml ghc-options: gcc ghc-options: "-optl-Wl,--allow-multiple-definition" ghc-options: "-optl-Wl,--whole-archive,../../hkl/.libs/libhkl.a,--no-whole-archive" ghc-options: "-optl-Wl,--whole-archive,../../binoculars/libhkl-binoculars.a,--no-whole-archive" but this time during the compilation I end up with this error message [1 of 3] Compiling Paths_hkl ( /home/experiences/instrumentation/picca/src/repo.or.cz/hkl/contrib/haskell/dist-newstyle/build/x86_64-linux/ghc-8.8.4/hkl-0.1.0.0/t/hkl-test/build/hkl-test/autogen/Paths_hkl.hs, /home/experiences/instrumentation/picca/src/repo.or.cz/hkl/contrib/haskell/dist-newstyle/build/x86_64-linux/ghc-8.8.4/hkl-0.1.0.0/t/hkl-test/build/hkl-test/hkl-test-tmp/Paths_hkl.o ) [2 of 3] Compiling BinocularsSpec ( test/BinocularsSpec.hs, /home/experiences/instrumentation/picca/src/repo.or.cz/hkl/contrib/haskell/dist-newstyle/build/x86_64-linux/ghc-8.8.4/hkl-0.1.0.0/t/hkl-test/build/hkl-test/hkl-test-tmp/BinocularsSpec.o ) <command line>: /home/experiences/instrumentation/picca/src/repo.or.cz/hkl/contrib/haskell/dist-newstyle/build/x86_64-linux/ghc-8.8.4/hkl-0.1.0.0/build/libHShkl-0.1.0.0-inplace-ghc8.8.4.so: undefined symbol: hkl_binoculars_cube_free both the executable and the test use this hkl_binoculars_cube_free function. So are you aware of a difference between test suit and executable during the build. more precisely are both executables compiled differently ? thanks for you help Frederic

3 7

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

Managing state between client/server (frontend/backend)
by Clinton Mead 02 Jan '22

02 Jan '22

A happy new year to all the Haskell community. My current role involves an app with a Scala backend and a React/Redux Javascript frontend. What should be quite simple tasks are made difficult/impossible, firstly by the fact if you even touch a Javascript codebase in any significant way you break the code in weird and wonderful ways, which may only be apparent as random runtime errors days, weeks or months in the future, but another issue is that tracking some bug back from the browser to the backend and the database is a nightmare because it's far from obvious what's going on across the language boundary between Scala and Javascript, particularly as everything is being flattened to JSON across that boundary. Anyway, I was thinking of a better way of doing this, and I thought it would be nice if much of the code was shared between the browser frontend and backend server though a common datatype, with the frontend just compiled with GHCJS. Some of the state to the client could be readonly, and some writable. The actual details of pushing the data back and forth would be abstracted away (as much as possible). When the client does writes, it wouldn't need to wait for the server to process these writes, it could just save these on the client side state, and send them off to the server to record, but otherwise continue on. There's quite a few nuances here I've started to think about (and there's likely more I haven't thought about) and given that I don't think this idea is particularly novel, are there any libraries out there that already do roughly what I'm talking about here? If someone has already thought this through I don't want to reinvent the wheel.

2 1