We enjoyed attending virtual MuniHac and would like to thank our co-organisers TNG for all the work they put into planning, hosting and and running the event. In particular, we’ve been very impressed with their Virtual Office software that was used during the event.
There were three tracks of talks during this two-day online event, and if you missed it, all the talks are available both on the MuniHac website and on YouTube.
Several of us contributed talks at MuniHac, including:
Being lazy without being bloated
Edsko de Vries
Laziness is one of Haskell’s most distinctive features. It is one of the two features of functional programming that “Why Functional Programming Matters” identifies as key to modularity, but it is also one of the most frequently cited features of Haskell that programmers would perhaps like to change. One reason for this ambivalence is that laziness can give rise to space leaks, which can sometimes be fiendishly difficult to debug. In this talk we will present a new library called nothunks which can be used to test for the absence of unexpected thunks in long-lived data; when an unexpected thunk is found, a “stack trace” is returned identifying precisely where the thunk is (“the second coordinate of a pair in a map in a list in type T”). In combination with QuickCheck, this can be used to test that an API does not create any thunks when it shouldn’t and thunks that are created are easily identified and fixed. Whilst it doesn’t of course fix all space leaks, it can help avoid a significant proportion of space leaks due to excessive laziness.
Contravariant logging: How to add logging without getting grumpy
Duncan Coutts
Logging usually makes me grumpy. It tends to clutter code and adds unnecessary dependencies. It’s just not beautiful.
I want to share the good news that there is an approach to logging that does not make me grumpy, and I have used it in a large project where it has worked out well. It is a a relatively new approach based on contravariant functors, that avoids cluttering the code, has a simple general interface that minimises concrete dependencies and still allows a choice of logging backend.
This talk will cover the problems with logging libraries, how contravariant logging improves things and how to apply contravariant logging in your project, with your choice of logging backend.
Addendum: Duncan forgot in his talk to mention the existing libraries that use the core idea. Duncan says:
My goal in the talk was to promote the contravariant logging idea as being a good idea. As I said in the talk I am certainly not trying to take credit for the idea. I should however have credited the people who did come up with the idea and mentioned the existing libraries that are based on this idea.
So to give credit where credit is due, to the best of my knowledge the idea was rendered into code several times in the last few years:
In 2016 by “rightfold” in the purescript-logging package
In 2017 by Renzo Carbonara in what would become the di-core package
In 2018 by Alex Vieth and which later ended up in the contra-tracer package
In 2018 by Dmitrii Kovanikov in the co-log-core package
I think it is great that this idea is being picked up and included in these libraries. As I argue in the talk however, we maximise the ability to use the pattern in different applications by minimising the assumptions. For example both di-core and co-log-core include additional “opinionated” functionality. I would like to see us get to the stage where there’s a package on Hackage that has just the minimal contravariant logging interface. That could be some future version of one of the existing library packages, or a core library shared between them.
Liquid Haskell (workshop)
Andres Löh
Liquid Haskell is an extension to Haskell that adds refinement types to the language, which are then checked via an external theorem prover such as z3. With refinement types, one can express many interesting properties of programs that are normally out of reach of Haskell’s type system or only achievable via quite substantial encoding efforts and advanced type system constructs. On the other hand, the overhead for checking refinement types is often rather small, because the external solver is quite powerful.
Liquid Haskell used to be an external, standalone executable, but is now available as a GHC plugin, making it much more convenient to use.
In this tutorial, we’ll discuss how refinement types work, give many examples of their use and learn how to work with Liquid Haskell productively.
Well-Typed Services
If you want to find more about what Well-Typed can offer, please check out our Services page, or just send us an email.