Welcome to another issue of Haskell Weekly! Haskell is a purely functional programming language that focuses on correctness, productivity, and expressiveness. This is a weekly summary of what’s going on in its community.
Want to see something featured in Haskell Weekly? We love contributions! Tweet us at @HaskellWeekly or open a pull request.
What I wish to be true: I write high level Haskell code as declaratively and naively as possible and sufficiently smart compiler optimizations make it as fast as hand tuned Go code. Let’s see if it works out that way!
Haskell doesn’t really have a call stack. The evaluation strategy is more like a graph reduction. If you don’t understand that, that’s okay — I don’t either! All I know about it is that it makes questions like “What’s the stack trace for this error?” surprisingly difficult to answer.
There are some useful warnings that are not turned on by
-Wall. This post will describe which additional warnings you should enable. It will also show examples of bad code that will trigger the warnings. Keep in mind that this bad code will not get caught by
Unfortunately, intuition and reasoning are not appearing in our types, and therefore we need to rely on our own inner reasoning checker instead of letting GHC enforce things for us. As things scale up, eventually it gets difficult to know what’s happening in the code.
With 8.2.1 at long last behind us, now is a good time to reflect on why these cycles are so long, what release schedule we would like to have, and what we can change to realize such a schedule.
Haskell’s error facilities are a lot better than most languages. This week we’ll look at some common error handling patterns. We’ll see a couple clear instances where Haskell has simpler and cleaner code.
We have managed to take a set of functionality that would have been exceptionally difficult to build using our old methods, and using the strengths of the Elm language and architecture, successfully developed the largest feature in our entire software product to date.
One has to be careful not to use
sever again to avoid ill effects: types have failed us once again. What we need is the ability to consume the old
s, to make it inaccessible. Which, coincidentally, is exactly what linear types enable.
The coinduction rule is not the direct dual of the induction rule, but both are specializations of more general, relational proof methods, where the duality is clearly present.
We traced these shortcomings to a missing key feature: It is not possible to carry statically generated cache files from one build to another once certain source files in the project change.
We are currently seeking to fill multiple devops positions, focusing on rolling out new build, deploy, and monitoring infrastructure. We are looking to hire both remote workers, and at least one engineer in the Phoenix, Arizona area for on site customer work.
- Gotta Go Fast: A command line utility for practicing typing
- Haskell in Leipzig 2017 submission deadline shifted
- I am a functional programming evangelist
- Invert your mocks!
- Meet Jenkins: GHC’s new CI and build infrastructure
- purerl updates for 0.11
- Streaming programs without laziness: A short primer
- The block in blockchain explained (Merkle trees)
- The oracle-free subset of Lamping’s abstract algorithm is Turing complete
- Today’s Stackage nightly snapshot uses GHC 8.2.1!
- What is new in cross compiling Haskell
- What’s the next best big thing for Haskell after dependent types?
- Yi modularization
Package of the week
This week’s package of the week is justified-containers, a library that provide guarantees about the presence of keys within containers.
Call for participation
- haskell-language-dockerfile: Test suite compilation failure with GHC 8.2
- solga: Build failure with GHC 8.2
- vty: Test suite build failure (due to GHC 8.2 perhaps)