October 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

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

[ANNOUNCE] GHC 9.2.1 now available
by Ben Gamari 17 Nov '21

17 Nov '21

Hi all, The GHC developers are very happy to at long last announce the availability of GHC 9.2.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1 GHC 9.2 brings a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merging of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [`-hi` profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Significant improvements in the bytecode interpreter, allowing more programs to be efficently run in GHCi and Template Haskell splices. * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Faster compilation and a smaller memory footprint * Introduction of Haddock documentation support in TemplateHaskell (#5467) 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 testing, - Ben [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

3 2

Type inference for lambda function
by Matthias Güdemann 04 Nov '21

04 Nov '21

Hi cafe, today while explaining lambda functions I came across this case which I don't really understand. This is what I get using ghci λ> :t (\a b -> a + b) (\a b -> a + b) :: Num a => a -> a -> a but when loading a .hs file with just this function (without signature) add = \a b -> a + b I get λ> :t add add :: Integer -> Integer -> Integer but I can explicitly define add to have this type: add :: Num a => a -> a -> a add = \a b -> a + b Also ghc infers this polymorphic type for example for add0 a = \b -> a + b Why is the type of add without a signature inferred to Integer and not Num a? Best regards Matthias

6 11

ghci's choice of names for type variables
by Julian Bradfield 01 Nov '21

01 Nov '21

I have tried to answer this by google and the list archives, but without success, though it wouldn't surprise me if there is a post buried somewhere. This is GHCI 8.10.7. When ghci infers types, it sometimes produces types with "a", with "t", and with "p" (and maybe others), as in the following set of examples: Prelude> h (x : xs) = x Prelude> :t h h :: [a] -> a Prelude> foo f x = not(f x) Prelude> :t foo foo :: (t -> Bool) -> t -> Bool Prelude> bar f x = (f x) + 1 Prelude> :t bar bar :: Num a => (t -> a) -> t -> a Prelude> barb f x g y = (f x)+(g y) Prelude> :t barb barb :: Num a => (t1 -> a) -> t1 -> (t2 -> a) -> t2 -> a Prelude> gar f x = f x Prelude> :t gar gar :: (t1 -> t2) -> t1 -> t2 Prelude> fooa x = x Prelude> :t fooa fooa :: p -> p What is its rationale? I have attempted to find it in the typechecker code, and I see things that suggest "t" is something to do with tau types (monotypes?), and "p" has something to do with levels, but going from basic Haskell and a modest theoretical acquaintance with System F to being able to read the GHCi type-checker is several steps too far! Can somebody give me a brief explanation of what's going on? In particular, is there actual information about the types in the choice of letters, or is it just incidental information about the way type inference proceeded? Thanks, Julian. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 3

German live interview about experiences with functional programming, today 12:00
by Henning Thielemann 01 Nov '21

01 Nov '21

https://www.heise.de/news/software-architektur-tv-Funktionale-Programmierun…

2 2

New CLC proposal process
by Andrew Lelechenko 30 Oct '21

30 Oct '21

I'm happy to announce that Core Libraries Committee has completed post-election reboot and now has a new home at https://github.com/haskell/core-libraries-committee <https://github.com/haskell/core-libraries-committee> and a new GitHub-based process: https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md <https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md>. From now on proposals to change base should be raised as GitHub issues instead of emails to libraries@. Best regards, Andrew

1 0

Re: [Haskell-cafe] ghci's choice of names for type variables
by Johannes Waldmann 30 Oct '21

30 Oct '21

Just from observing the behaviour (not the source) - it seems that ghci tries to use the variables from the declaration of the/a function, type, or class that is being used. Prelude> data T c = T c Prelude> h x y = (T x, T y) Prelude> :t h h :: c1 -> c2 -> (T c1, T c2) Prelude> f :: foo -> foo ; f x = x Prelude> g = f Prelude> :t g g :: foo -> foo In the Haskell Standard, type variables are a, b, ... mostly (always?), hence you get `a` for anything with lists and Num. If there's no type to refer to, then your examples show that it's using t or p, but I don't know how. Prelude> i x = x Prelude> :t i i :: p -> p Prelude> k x y = x Prelude> :t k k :: p1 -> p2 -> p1 Prelude> s x y z = x z (y z) Prelude> :t s s :: (t1 -> t2 -> t3) -> (t1 -> t2) -> t1 -> t3 interesting! - J.W.

1 1

Re: [Haskell-cafe] simple word processor
by Olaf Klinke 27 Oct '21

27 Oct '21

> I am new to haskell and I need to create a simple word processor. It needs > to read text from the cmd and implement functions that would edit functions > found in the text so some other text.All functions in the text are odered. > Each function i.e section,table,figures and ref must be located and > numbered independently based on the order of occurence. Since tables and > figures are within the sections function(just like a book), when a new > section is encountered you will reset the value of tables and figures. So i > did a loop where the tables and figures are inside the section loop when > searching for the functions. The functions all start with this '' character > (escape character) and must be replaced with text using this method: > \Section{title}{id}: -> "Section n: title". Where n is the section number. > \table{title}{id} : -> "Table n.m : title". Where n is the number of the > last section encountered and m is the table number. And so on. Let me try to break your problem into sub-problems. 1. You have text where some patterns have meaning to your particular application (e.g. "\Section{title}{id}"). 2. When knowing this structure, you want to transform it from front to back while updating some counters. 3. Once that transformation is done, you want to write the structure back into a plain text. How to approach: 1. is addressed with parsers. There are plenty to choose from, e.g. parsec, attoparsec, megaparsec to name just tree applicative-style libraries. A parser looks for patterns in plain text and transforms it into a more stuctured type. The structured type may be somethig like data Block a = SomeText Text | Section Text a | Table Text s | etc. The parsing function will have a type similar to Text -> Either ParseError [Block ()] where () stands for a numbering that is not yet known. 2. May be modeled as a stateful traversal. First define a state with all the counters, say data Counters = Counters { theSection :: Int, theTable :: Int} Next define a traversal function Block () -> State Counters (Block Text) where the unknown numbering () is replaced with the appropriate Text- representation of theSection or (theSection,theTable) etc. Finally, traverse your parsed list of Blocks with this traversal. 3. essentially requires a Show instance for your (Block Text) type together with concatenation. Steps 1-3 will be combined like follows. fmap ((=<<) show . flip evalState start . traverse number) . parse where parser :: Text -> Either ParseError [Block ()] start :: Counters number :: Block () -> State Counters (Block Text) "traversal" -> hoogle for Data.Traversable "stateful" -> hoogle for Control.Monad.State Olaf

1 0