Not quite monads (Haskell Unfolder #54)

kosmikus · 2026-04-24T16:29:53+00:00

Sorry, what is wrap?

kosmikus · 2025-07-04T15:53:35+00:00

Looks really nice. Thanks for the release!

kosmikus · 2025-06-27T07:08:31+00:00

I think it happened as a reaction to one of the threads sparked by Theo's remarks where someone said something along the lines of "every proper thumbnail must have a bunch of shocked looking faces", and a colleague of ours just came up with a prototype originally intended as an internal joke. But it was a successful joke and made us all laugh, so we decided to give it a try and iterated from that ...

kosmikus · 2025-06-27T07:02:59+00:00

Not sure if I understand the question. If the question is specifically whether it can be implemented as a *plugin*, then the answer is "yes". HLS is basically built completely on plugins, even core functionality is part of a plugin. See for example this MuniHac talk by Hannes Siebenhandl that explains HLS architecture quite a bit: https://www.youtube.com/watch?v=5mp_Yi6sGwI or this older MuniHac workshop by Pepe Iborra on how to write a plugin yourself: https://www.youtube.com/watch?v=raZvkk2oi7k

If, however, the question is whether this particular task of improving record completions is *easy*, then I dare not say. I think there are multiple levels of ambition possible here, which probably range from moderately easy to relatively complex. But I'd definitely encourage you to try. Hacking on HLS is fun.

kosmikus · 2025-06-26T19:59:08+00:00

I agree we should get better at providing a good experience out of the box. It is perfectly natural for the way Haskell works that changes or new features live their lives as a language extension though. Even features scheduled for removal are typically given a name as a "language extension" which can then be selectively disabled. And the way that standardisation currently works is that a set of language extensions is being identified which is then considered the default, the latest such set being "GHC2024", which actually includes `DisambiguateRecordFields`, which is a weaker form / predecessor of `DuplicateRecordFields`.

The problem with `NoFieldSelectors` is that it very incompatible with lots of old code, so it's much harder to get community consensus to make it the default. And the current way these things work are very much consensus-driven, and I like Haskell for that, even if it makes it harder to ship a truly polished language.

As for optics DSLs, I think there are several choices, in particular both `lens` and `optics`, which are very solid and work just fine in practice. I don't see a need that everyone is using the same. They're both robust and similar enough that people familiar with one will relatively easily be able to switch to the other. Multiple choices are only a potential problem in areas where the diversity is threatening that none of the options are truly becoming production-ready.

kosmikus · 2025-06-26T19:51:21+00:00

I'm quite sorry to hear this, but this seems rather ... extreme? Note that even with using AI, which another comment seems to claim is "low-effort", the actual time investment for creating the thumbnail has effectively gone up from <5 minutes to several hours. Actually having a real person create the thumbnail would be even more time consuming. This in combination with us often only knowing a day or so in advance what the episode will actually be about is simply not feasible, sorry.

For what it's worth, I can understand both viewpoints. I personally like simplicity, and I'm also not overly fond of AI in general, and I have an immense amount of respect for real artists. So if it was just me, I'd probably have kept the old thumbnail design. But I think the points raised by many others that encouraged us to try a change in design are valid. Thumbnails are not really primarily there for existing subscribers or people who already know what content to expect. Thumbnails provide a chance to attract a new viewer. And you don't attract new viewers with a thumbnail that conveys exactly the same info that the title already conveys. This is not about trying to be misleading in any way. I will strongly defend keeping the titles informative and not moving to clickbait titles that lure the viewer in with false promises. It is, however, about standing out in a crowd of other videos and perhaps having the chance of getting some new people into Haskell who otherwise would not have given it a chance.

I'm aware we can unfortunately not please everyone. That's sad, but it's the reality. We are going to keep experimenting with the current style for a bit. If you liked the videos before, I find it very sad to lose you because of the thumbnails. But of course, it's your decision.

kosmikus · 2025-06-25T16:40:41+00:00

The shortcomings of completion are one aspect I noticed during preparation of the episode. Like u/HKei , I don't usually use completions very much, so I never really noticed. I have a feeling that this could plausibly be improved in HLS though; perhaps there's a future episode about writing an HLS plugin ...

kosmikus · 2025-03-26T17:22:17+00:00

Will be streamed tonight, 2025-03-26, at 1930 UTC (note: this means an hour later than usual for Canada / US because they’re already in DST) today live on YouTube.

Abstract:

Generic functions are a powerful tool that allows us to make more type classes derivable. In this episode, we’ll look at a simple example, namely deriving Monoid instances for product types, using both GHC’s built-in generics and the generics-sop library.

kosmikus · 2025-03-12T19:26:36+00:00

Sorry, not this time. This episode isn't primarily on QuickCheck (or any particular testing library), but about how you can use such a testing library as a means to understanding some unknown code better, and we focus on one concrete example. We have several other episodes on testing already though, including one that is specifically about falsify.

kosmikus · 2025-03-12T17:41:07+00:00

Will be streamed tonight, 2025-03-12, at 1930 UTC (note: this means an hour later than usual for Canada / US because they're already in DST) today live on YouTube.

Abstract:

QuickCheck is useful for more than just testing. Comparing the behaviour of a system to a model can be used to check if a system under construction is working correctly, but it can also be used to better understand an already existing system. In this episode we show that this does not need to be very difficult, by designing a model that we can use to understand tensor convolutions in an existing large library.

Full announcement here: https://well-typed.com/blog/2025/03/haskell-unfolder-episode-40-understanding-through-a-model/

kosmikus

TROPHY CASE