December 2021 - Haskell-Cafe

[ANN] cabal-clean (new tool)
by Andreas Abel 19 Aug '22

19 Aug '22

=== Wondering where your disk space goes with too many Haskell projects compiled with too many GHC versions? === https://hackage.haskell.org/package/cabal-clean https://github.com/andreasabel/cabal-clean `cabal-clean` is a small executable that removes outdated cabal build artifacts from `dist-newstyle`. A build tree is considered outdated if there is one with either - a newer version of the package you are building, or - a newer minor version of the GHC compiler. In contrast to `cabal clean`, the tool `cabal-clean` retains the latest build trees for each GHC major version. Thus, it is geared towards multi-GHC development. Example: (self-applied to cabal-clean's build directory) --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 The directories prefixed with --- will be deleted, the ones with +++ retained. Disclaimers: 1. cabal-clean does not check whether deletion will cause dangling references like broken symlinks etc. (Could happen if you created a symlink to an executable that resides in one of the deleted build directories.) 2. cabal-clean does not read nor utilize information from the .cabal file. 3. Calls `du` ("disk usage"), so, might not work on Windows. Enjoy, Andreas

6 6

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

Coercing existential according to type-level Maybe (re-post from h-beginners)
by Dmitriy Matrosov 29 Jan '22

29 Jan '22

(as suggested, i'm re-asking here) Hi. I've tried to write a function to coerce existential value according to type stored in type-level 'Maybe' (i.e. 'Just or 'Nothing). > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE GADTs #-} > > import Data.Kind > import Data.Proxy > import Unsafe.Coerce > > class FromTypeMaybe k where > type ToType k > fromTypeMaybe :: (a -> ToType k) -> Proxy k -> a -> Maybe (ToType k) > > --instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe t) where > instance forall (t :: Type). FromTypeMaybe ('Nothing @t) where > type ToType 'Nothing = t > fromTypeMaybe f _ x = Nothing > > instance forall (t :: Type). FromTypeMaybe ('Just t :: Maybe Type) where > type ToType ('Just t) = t > fromTypeMaybe f _ x = Just (f x) > > data Any where > Any :: a -> Any > > unAny :: Any -> t > unAny (Any x) = unsafeCoerce x This works as far as i can see *Main> fromTypeMaybe unAny (Proxy @('Just Int)) (Any 3) Just 3 *Main> fromTypeMaybe unAny (Proxy @'Nothing) undefined Nothing but i don't understand how 'Nothing instance works: type kind kind? vvv vvvvvv vvv instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe t) where type ToType 'Nothing = t ^^^ type (in case alignment breaks: variable 't' in forall is type-variable with kind 'Type', but in "Maybe t" in instance head it's used as kind-variable. And then in associated type-family the same variable 't' is used as type-variable again). If i try to write "'Nothing"'s kind as 'Maybe Type' (in the same manner as 'Just has) instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe Type) where i get an error: 1.lhs:21:3: error: • Type variable ‘t’ is mentioned in the RHS, but not bound on the LHS of the family instance • In the type instance declaration for ‘ToType’ In the instance declaration for ‘FromTypeMaybe ('Nothing :: Maybe Type)’ | 21 | > instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe Type) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Well, i'm not sure, that understand why 'forall' in instance head may not be used as family's LHS, but.. that's another question. On the other hand, if i try to write 'Just instance using type-variable 't' as kind-variable (in the same manner as 'Nothing has): instance forall (t :: Type). FromTypeMaybe ('Just t :: Maybe t) where i get an error too: 1.lhs:25:47: error: • Expected kind ‘Maybe t’, but ‘'Just t’ has kind ‘Maybe *’ • In the first argument of ‘FromTypeMaybe’, namely ‘('Just t :: Maybe t)’ In the instance declaration for ‘FromTypeMaybe ('Just t :: Maybe t)’ | 25 | > instance forall (t :: Type). FromTypeMaybe ('Just t :: Maybe t) where Well, that's also probably expected, because though i've declared type-variable 't' with kind 'Type' in forall, due to 'DataKinds' extension type 't' is also promoted to kind 't' and, thus, by using ('Just t :: Maybe t) i say, that ('Just t) should have kind 'Maybe t', not 'Maybe Type', which it really has. But if that's so, how working 'Nothing instance instance forall (t :: Type). FromTypeMaybe ('Nothing :: Maybe t) where may work at all? It has the same problem as 'Just instance above: type-variable 't' is promoted to kind 't' and 'Nothing will have kind 'Maybe t' instead of 'Maybe Type' ?

3 10

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

text-2.0 with UTF8 is finally released!
by Andrew Lelechenko 26 Dec '21

26 Dec '21

I’m happy to announce that text-2.0 with UTF-8 underlying representation has been finally released: https://hackage.haskell.org/package/text-2.0. The release is identical to rc2, circulated earlier. Changelog: https://hackage.haskell.org/package/text-2.0/changelog Please give it a try. Here is a cabal.project template: https://gist.github.com/Bodigrim/9834568f075be36a1c65e7aaba6a15db This work would not be complete without a blazingly-fast UTF-8 validator, submitted by Koz Ross into bytestring-0.11.2.0, whose contributions were sourced via HF as an in-kind donation from MLabs. I would like to thank Emily Pillmore for encouraging me to take on this project, helping with the proposal and permissions. I’m grateful to my fellow text maintainers, who’ve been carefully reviewing my work in course of the last six months, as well as helpful and responsive maintainers of downstream packages and GHC developers. Thanks all, it was a pleasant journey! Best regards, Andrew

3 2

[Haskell] [ANNOUNCE] GHC 9.0.2 released
by Zubin Duggal 25 Dec '21

25 Dec '21

The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at the [usual place](https://downloads.haskell.org/ghc/9.0.2/). Download Page: https://www.haskell.org/ghc/download_ghc_9_0_2.html Blog Post: https://www.haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html GHC 9.0.2 adds first class AArch64/Darwin support using the LLVM backend, as well as fixing a number of critical correctness bugs with the 9.0.1 release, along with numerous improvements to compiler performance and memory usage: * First-class support for Apple M1 hardware using GHC's LLVM ARM backend. * Fix a number of incorrect rewrite rules for `fromInteger` (#19345, #20066). * Fix a number of runtime system and GC bugs which typically manifested in crashes (#19417, #19297, #19645, #19667, #18033, #20132, #19715, #20399, #20414, #20649, #19147, #20051, #20093) * Fixes for various compiler performance and memory usage issues (#20134, #13586, #20509, #19668, #19996, #19471) * Improvements and bug fixes for the code generator and optimiser (#18638, #19581, #19700, #19996, #19181, #19822) * Fixes for typechecker bugs (#19410 , #19191, #19522, #19400, #19849) * Bug fixes for the frontend and parser (#19397, #19838, #19518, #19777, #20242, #19786) * Emit warnings if Unicode Bidirectional Formatting characters are found in the source, possibly misleading code reviewers (#20263). * Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `native` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Some previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. * A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) * Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/9.0.2/docs/html/users_guide/9.0.2-…. Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do open a [ticket][] if you see anything amiss. Happy Holidays and Happy Hacking! - Zubin

2 2

CFP (Deadline Extended): The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022
by Shashank Swarup 23 Dec '21

23 Dec '21

*************************************************************************** The 5th International Conference on Emerging Data and Industry 4.0 (EDI40) Porto, Portugal March 22-25, 2022 *************************************************************************** Conference Website: http://cs-conferences.acadiau.ca/EDI40-22/ Workshops: http://cs-conferences.acadiau.ca/EDI40-22/#workshop Important Dates - Workshops Proposals Due: October 1, 2021 * - Paper Submission Due: December 30, 2021 (Revised & Firm)* - Acceptance Notification: January 15, 2022 - Camera-Ready Submission: February 10, 2022 EDI40 2022 accepted papers will be published by Elsevier Science in the open-access Procedia Computer Science series on-line. Procedia Computer Science is hosted by Elsevier on www.Elsevier.com and on Elsevier content platform ScienceDirect (www.sciencedirect.com) and will be freely available worldwide. All papers in Procedia will be indexed by Scopus ( www.scopus.com) and by Thomson Reuters' Conference Proceeding Citation Index (http://thomsonreuters.com/conference-proceedings-citation-index/) All papers in Procedia will also be indexed by Scopus (www.scopus.com) and Engineering Village (Ei) (www.engineeringvillage.com) This includes EI Compendex (www.ei.org/compendex) Moreover, all accepted papers will be indexed in DBLP (http://dblp.uni-trier.de/) The papers will contain linked references, XML versions and citable DOI numbers. You will be able to provide a hyperlink to all delegates and direct your conference website visitors to your proceedings. Selected papers will be invited for publication, in the special issues of: - International Journal of Ambient Intelligence and Humanized Computing (IF: 4.594), by Springer (http://www.springer.com/engineering/journal/12652) - International Journal Personal and Ubiquitous Computing (IF:3.006), Springer (https://www.springer.com/journal/779) - International Journal on Transportation Research Part A: Policy and Practice (IF: 3.992), by Elsevier ( https://www.journals.elsevier.com/transportation-research-part-a-policy-and… ) - International Journal of Computing and Informatics (IF: 0.524), by Computing and Informatics (http://www.cai.sk/ojs/index.php/cai/index) EDI40 2022 will be held in Porto, Portugal. Porto is the second-largest city in Portugal after Lisbon and one of the major urban areas of the Iberian Peninsula. Porto is also called the Invicta because during the 19th century Portuguese civil war, the city withstood a siege of over a year.The urban area of Porto, which extends beyond the administrative limits of the city, has a population of 2.1 million in an area of 389 km2 (150 sq mi), making it the second-largest urban area in Portugal. It is recognized as a gamma- level global city by the Globalization and World Cities (GaWC) Study Group, the only Portuguese city besides Lisbon to be recognized as a global city. EDI40 will be held in conjunction with the 13th International Conference on Ambient Systems, Networks and Technologies (ANT 2022). Conference Tracks - Benefits of Industry 4.0 - Big Data and Analytics - Cloud Computing - Cognitive Computing - Computational Intelligence - Cyber-Physical Systems (CPS) - Fog Computing and Edge Computing - Internet of Everything (IoE) - Standards for IoT Application Integration - The New Business Models in Industry 4.0 - General Track: Digitalization Startegies Committees General Chair Danny Hughes, CTO VeraSense NV, Belgium Program Chairs Jamal Bentahar, Concordia University, Canada Haroon Malik, Marshall University, USA Local Chair Nuno Varandas, F6S (Where Founders Grow Together), Portugal Workshops Chair Stephane Galland, UTBM, France Program Advisory Committee Reda Alhajj, University of Calgary, Canada Ladislav Hluchy, Institute of Informatics, Slovak Academy of Sciences, Slovakia Vincenzo Loia, University of Salerno, Italy Peter Sloot, Universiteit van Amsterdam, Netherlands Peter Thomas, Manifesto Research, Australia Mohamed Younis, University of Maryland Baltimore County, USA International Journals Chair Michael Sheng, Macquarie University, Australia Publicity Chairs Wim Ectors, Hasselt University, Belgium Faouzi Kammoun, Ecole SupÃƒÂ©rieure PrivÃƒÂ©e d'IngÃƒÂ©nierie et de Technologies, Tunis Aneta Poniszewska-MaraÃ…â€žda, Lodz University of Technology, Poland Shashank Swarup, Acadia University, Canada Technical Program Committee http://cs-conferences.acadiau.ca/EDI40-22/#programCommittees International Liaison Chairs Soumaya Cherkaoui, Sherbrooke University, Canada Nik Bessis, Edge Hill University, UK David Taniar, Monash University, Australia Steering Committee Chair and Founder Elhadi Shakshuki, Acadia University, Canada

1 0

3 Fully funded PhD positions in Software Technology at Radboud University, Netherlands
by Peter Achten 20 Dec '21

20 Dec '21

-------------------------------------------------------------------------------------- 3 Fully funded PhD positions in Software Technology at Radboud University, Netherlands -------------------------------------------------------------------------------------- In the Software Technology group at Radboud University in Nijmegen, Netherlands, we are looking for enthusiastic and outstanding Computer Science or Mathematics students with a strong background in at least one of the following areas: * programming languages * compiler technology * code generation * runtime systems * High-Performance-Computing * Parallel Computing to strengthen our group. Our key driving force is the desire to combine programming language research with compiler technology and code generation techniques for creating practically applicable software tools. Our credo lies in HP3 technology: combining High-Productivity, High-Portability, and High-Performance. Long-term projects driven by our group include the Clean project (clean.cs.ru.nl), the SaC project (www.sac-home.org) and the iTask system (clean.cs.ru.nl/ITasks). Our current focal points are: *Gradual Programming*, *Swarm Computing*, *Heterogeneous High- Performance Computing*, *Sustainable and Energy-Efficient Computing*. With *Gradual Programming*, we aim to combine the flexibility of rapid prototyping with the type safety of strongly typed programming languages. We look into a radically new approach towards typing programming languages for increased productivity, correctness and sustainability. Please contact Peter Achten (P.Achten(a)cs.ru.nl) for details. *Swarm Computing* refers to the idea of being able to, from a single source, perform programming, controlling, and computation on a dynamic and hybrid collection of computational units varying from CPUs, GPUs, FPGAs, TPUs, to IoT devices. Currently, we are particularly interested in Swarm Computing for sustainable IoT utilisation. Please contact Pieter Koopman (pieter(a)cs.ru.nl) for details. In *Heterogeneous High-Performance Computing*, we are interested in the generation of code for swarm computing systems aiming for unprecedented levels of efficiency in terms of both, runtime and energy efficiency. This includes mainstream accelerators such as GPUs and FPGAs as well as novel architectures such as Cerebras’ new architecture (www.cerebras.net) This work will contribute to the new TEN-X initiative (mission10-x.org) Please contact Sven-Bodo Scholz (SvenBodo.Scholz(a)ru.nl) for details. We offer: * a gross monthly salary starting from €2,434 in the first year, step-wise increasing to €3,111 in the fourth year. * a 4 year full-time contract, subject to a successful performance evaluation after 18 months. * a stimulating work environment with excellent Dual Career and Family Care Services. = How to apply = Applications should consist of a single pdf-file containing your CV, a cover letter explaining your motivation, and a letter of reference. We will consider applications as they arrive until the positions are filled. The deadline for applications is January 31 2022. Please send your application to: SvenBodo.Scholz(a)ru.nl.

1 0

Package takeover request for oath
by Fumiaki Kinoshita 17 Dec '21

17 Dec '21

At the moment, oath is registered as a "reserved package name" (see https://mail.haskell.org/pipermail/libraries/2021-December/031524.html) and does not exist as an actual package. I'd like to upload a package with this name unless there's a specific reason why I should not. My Hackage username is FumiakiKinoshita. Best regards,

3 6

install error: sym
by Gregory Guthrie 15 Dec '21

15 Dec '21

Seems like this is a package error? Sym\Perm\STAT.hs:13:8: error: File name does not match module name: Saw: `Sym.Perm.Stat' Expected: `Sym.Perm.STAT' Install log: PS C:\Users\guthrie\Desktop> cabal install sym Resolving dependencies... Build profile: -w ghc-8.10.2 -O1 In order, the following will be built (use -v for more details): - base-orphans-0.8.6 (lib) (requires download & build) - primitive-0.7.3.0 (lib) (requires download & build) - hashable-1.4.0.1 (lib) (requires download & build) - vector-0.12.3.1 (lib) (requires download & build) - sym-0.13.0 (lib) (requires download & build) Downloading base-orphans-0.8.6 Downloaded base-orphans-0.8.6 Downloading primitive-0.7.3.0 Starting base-orphans-0.8.6 (lib) Downloaded primitive-0.7.3.0 Downloading vector-0.12.3.1 Starting primitive-0.7.3.0 (lib) Downloaded vector-0.12.3.1 Downloading hashable-1.4.0.1 Downloaded hashable-1.4.0.1 Downloading sym-0.13.0 Downloaded sym-0.13.0 Building base-orphans-0.8.6 (lib) Building primitive-0.7.3.0 (lib) Installing base-orphans-0.8.6 (lib) Completed base-orphans-0.8.6 (lib) Starting hashable-1.4.0.1 (lib) Building hashable-1.4.0.1 (lib) Installing primitive-0.7.3.0 (lib) Completed primitive-0.7.3.0 (lib) Starting vector-0.12.3.1 (lib) Installing hashable-1.4.0.1 (lib) Building vector-0.12.3.1 (lib) Completed hashable-1.4.0.1 (lib) Installing vector-0.12.3.1 (lib) Completed vector-0.12.3.1 (lib) Starting sym-0.13.0 (lib) Building sym-0.13.0 (lib) Failed to build sym-0.13.0. Build log ( C:\Users\guthrie\AppData\Roaming\cabal\logs\ghc-8.10.2\sym-0.13.0-6a5a01f540d09f303c049bc421a706632878562d.log ): Preprocessing library for sym-0.13.0.. Building library for sym-0.13.0.. Sym\Perm\STAT.hs:13:8: error: File name does not match module name: Saw: `Sym.Perm.Stat' Expected: `Sym.Perm.STAT' | 13 | module Sym.Perm.Stat | ^^^^^^^^^^^^^ cabal.exe: Failed to build sym-0.13.0. See the build log above for details. Dr. Gregory Guthrie

4 5