Haskell Weekly

Hi! Welcome to the Haskell Weekly podcast. This is a show about Haskell, a purely functional programming language. I'm your host, Taylor Fausak. I'm the lead engineer at ITProTV, an ACI learning company. And with me today is Cameron Gera, one of the engineers on my team. Thanks for joining me today, Cam.

>> Of course, man. I'm glad to be back after, you know, a week off. Sorry to all of our listeners who didn't get that Monday morning joy of Haskell Weekly coming out.

>> Well it's all right. We're gonna be reliving last week this week because there was a lot of good news that we want to go over. And, uh, yeah, just all kinds of crazy stuff happening in the world of GHC.

>> Yeah, GHC started off 2021 with a bang. You know, we've already talked about you know, the GHC 2021 grouping of language extensions. And today we're gonna be kind of diving in, Um, to more awesome news in GHC and just the Haskell community in general. Um, and I think our first kind of order uh, yeah, order of business here is to congratulate the Haskell Foundation for picking their executive director and chief technology officer. Um, those are two positions that I think with the people they chose is going to do great things. Um, I know Taylor, you have a little bit more experience with who they chose. Do you want to kind of talk more about that?

>> Sure, I'd be happy to. So on the discourse for Haskell, which is like, you know, the forum. Simon Peyton Jones announced that the Haskell Foundation picked the executive director and the chief technology officer. Like you said, uh, the executive director is Andrew Boardman, and I actually had not heard of him before. Haven't interacted with him, but there's a little intro there in the post. We'll have a link in the show notes. And he sounds like a great guy and, you know, ready to helm this new foundation and lead it in a good direction. So I'm looking forward to what he's able to do. Um, and also the chief technology officer, which was kind of like a bonus selection for the Haskell Foundation. I think they only intended to pick an executive director, but um, everybody was so on board with this person that, you know, they were able to give her a role. So Emily Pillmore is the CTO for the Haskell Foundation. Um, I have interacted with her. She's a great person, and she's gonna be in charge of all the technical decision making for the foundation itself.

>> I think that's awesome. Congratulations, Andrew and Emily. We look forward to seeing how the Haskell Foundation flourishes under your guys's leadership. So I'm really excited about that.

>> Yeah! I think this is an important step for the foundation. And, uh, I think we may have talked about it a little bit before, maybe last year even. But for those not in the know, the Haskell Foundation, um is still kind of nascent, like still coming together a little bit. But the intent is to have, like, one guiding light for the Haskell community slash ecosystem. Or to put it another way to kind of bring together all of these disparate communities and groups that Haskell has, like the Haskell.org committee and the core Libraries Committee and all the people that maintain all these different packages having a common area for all of them, you know, to pool resources or ask for help or that type of thing and and many other things. So, really looking forward to the Haskell Foundation. This is a excellent start.

>> Yeah, it seems like it's gonna make a big waves for Haskell in the overall programming. You know, realm. Um, you know, obviously there's large organizations that use Haskell, but a lot of people don't know that. Um and so I think having a foundation that is centered around creating this, you know, awareness and education around Haskell, what can provide you will really allow other organizations to hear that and be like, Okay, let's give it a shot. So, Think it's great for, you know, all the Haskellers out there because it will eventually mean more job opportunities.

>> Exactly. And we're not a large company, but we're a small company, and we use Haskell. And I think there's some good stuff. Uh, you know, even for us, like you mentioned, it'll be easier to hire Haskell people in the future. If the Haskell Foundation succeeds at what it's trying to do, which I think it will. So shall we move on to some of the GHC news?

>> Oh, yeah. Drumroll, please.

>> Well, we're going to start with a small one. So The GHC 8.10.4 was released, and this is a very small bug fix release, but it's probably the end of the line for the 8.10 series. And this one's important. It shores up a couple bugs with windows, um, and linking and some other little things. So pretty much if you're currently using 8.10 dot something, you should upgrade to 8.10.4.

>> Yeah. Shouldn't really have any obviously major breaking changes and should allow you to be up to date. Um, you know, maybe maybe we gotta pour one out for the 8.10 series, you know, be like it's done a lot of good for the Haskell world.

>> Yeah. I mean, we're still using it at work. Um, and we were fortunate because we're we use stack and Stackage and the most recent version of Stackage. Both nightly and LTS use 8.10.4. So it's a pretty seamless upgrade for us.

>> Nice Well, you know, we keep talking about this being the last of the series. Well, what's next? What's next for GHC? Um, and I love you to announce that. Good, Sir Taylor.

>> So the big ticket release is G.H.C. 9.0.1. Um, this has been, um, a lot of people have been very excited about this release and for good reason. There's a lot of big ticket things that landed here that are, um maybe not fundamental changes to Haskell, but, um, very big changes. So the biggest one, perhaps, is the addition of linear types through a language extension on that comes to us in GHC 9. So now you can download the compiler and try out linear types.

>> I know you were, you know, still learning more about linear type because it's not obviously something we used in our current Haskell, um, implementations because it hasn't really been available to us. What's kind of some examples of what linear types help with those who may not know.

>> Yeah. So I don't feel super qualified to be an authority on this, because I don't know a lot about linear types myself. Um, the way that I understand it maybe the best, like go to example of what our linear types or what they can help. What can they help with is to look at rust. And there's an important caveat here that Rust doesn't actually have linear types. It has a related thing called affine types. Um, and my understanding is that the differences with linear types, um, you have to use your argument once, like exactly one time and with affine types, you have the choice. You can either use it or not. Um, so it seems like kind of a pedantic difference, and it probably is. But by and large, if you're wondering what are linear types, I think it's what Rust does is a reasonable way to look at it.

>> Okay, cool. Awesome. Well, let's get on to the next one that I know you're thrilled about. I feel like this is the one where you're like, GHC 9's out, and this is what it gives us like it's qualified do, right? Like, what's the deal with qualified do? Why is it awesome?

>> Yeah, So this one, it's kind of funny because it ties in with linear types quite a bit, um, but only they're sort of orthogonal to each other, but they both benefit each other. So qualified do means that normally, if you use do notation in a Haskell program, it will use the bind operator from the prelude that greater than greater than Equal Sign Operator, which works for the monad class. Um, there have been ways to change how that works. There's a There's a very big hammer of a language extension called rebindable syntax that lets you choose whatever bind operator you want. But what qualified do lets you do is for each at each place where you use the keyword. Do you can qualify it like you would any other identifier or operator in your program, and you could say some monad dot do, And then within that block, it will use some monad dot bind rather than the one from the prelude. So this might sound kind of pointless, like for most, most of the monads that most people use most of the time using a lot of weasel words here, uh, it won't matter because, like, you know, you could do a ReaderT and that'll work with monad whatever. But if you wanted to use, for instance linear types with a linear monad, it wouldn't type Check. I'm pretty sure again, I'm not an authority on linear types, but, uh, yeah, it can allow you to do new, more powerful things. Um, there's a related concept called indexed monads. Hopefully I I think it's related you could do index monads with qualified do, um Or if you just wanted to be more specific and say, like, maybe dot do or, you know, list dot Do or something like that. A little more Elm-ish in the explicitness.

>> Yeah, Yeah, that's what I was kind of picturing when you first started talking about qualified. Do was like, maybe dot do list dot do, um and just kind of explicitly setting the monad in which the two up, you know, which we're working in. I think that's kind of Ah, you know, I'm excited to see what it does for us. I don't think for me right now. I don't see us gaining a ton of benefits from it, but I also don't. I've never used it. I don't understand fully why it would be super great, but I'm excited to learn and, you know, kind of take those steps towards seeing the significance in this, um, in the version. Bump.

>> Yeah, I am, too. And I think one area that this might be kind of abused a little bit is that you could use qualified do to make a DSL that just happens to use do notation to, like, split things up on the separate lines. So if you wanted to write like a, you know, Web server router, where you put the routes each on their own line and the Scotty library kind already does this anyway. But you could do that without actually having to implement a monad behind the scenes, which maybe could be helpful. I'm not sure it would depend on exactly what you're implementing. So it might be nice and some other weird ways We'll see what the community does with it. I like you. I'm excited to see where this goes.

>> Yeah, awesome. Well, we've got another think. Biggest change related to GHC bignum

>> Yeah. Big change, bignum.

>> Oh, yeah. How it's gonna replace the integer GMP.

>> Mhm. So I could give a little bit of color commentary here. So, um, when you use arbitrary precision, integrals in Haskell. So, like the integer type or the natural type where they're unbounded, they could be as big as you want behind the scenes, those are using currently with like 8.10 and before they're using a library called integer GMP. GMP stands for the GNU multiple precision. Something like that. Anyway, uh, some people dislike this library because it is licensed with the GPL, which is like a copyleft license so. There's a replacement library called integer simple, but it's a lot slower, and it's written in pure Haskell rather than integer GMP, which I think is either C or C++ so GHC bignum is trying to get the best of both worlds here, where you can have arbitrary precision integers and you can use them without using GPL licensed code. And it will be code that's maintained by GHC and I think mostly written in Haskell. I don't know what the implementation of bignum looks like, so it's a little behind the scenes, but it's a good change nonetheless.

>> Yeah, it seems like it will give you give programmers a little more freedom. Uh, so that's cool. Awesome. Um, all right, so we have the next ticket item here, which is simplified subsumption setting things up for quick. Look impredicativity.

>> That's a mouthful. Yeah. So this is this is something that I am definitely not qualified to remark on. Um, I know that. Yeah. Impredicativity? Come on. Um, I know that Richard Eisenberg, who is actually the chair of the Haskell Foundation board, um, he has a YouTube channel where he's doing, like, these kind of quick bites of explaining concepts because he's a He's a GHC contributor. Very smart guy. And he's, you know, pushing on some of this quick look impredicativity stuff. So if you want to know more about it, I would recommend find that YouTube channel or look at what he's written. He's excellent communicator, and it's my own fault that I don't know any about any of this stuff, so yeah, um but yeah, this is just some changes to the type system that are coming, and I think they'll be good.

>> Yeah, And if you know more about any of these topics. And you have any interest in being on the podcast and explaining them for us like we would love to have You we're always looking guests on the podcast. So just a quick sidebar there. Uh huh. But yeah. So now I think this language extension that's coming with GHC 9.0.1 will help us and, I think, help the community, which is the new lexical negation. A situation that we have.

>> Yeah. So now we're into the area of things. I feel very comfortable being an authority on. So lexical negation, uh, basically means it's a language extension, like you said. And what it means is that the spacing around a negative sign will be important. So normally in current Haskell, if you write X minus one, that pretty much always means X minus one. Um, whether or not it's X space minus space one or all run together or any variation with lexical negation. If you do X space minus space one that means X minus one like it always did. But if you do X space minus one kind of smushed together, then that minus one will be a single unit and won't mean minus one anymore. Um and this seems a little nitpicky. Maybe, but something similar already happens with the dot or the period where sometimes it means like a qualified thing, Right. If you have some name dot some identifier, then it's a qualified thing. But if you put spaces in there, suddenly it means function, composition or whatever. Operator, you have imported usually function composition. So I think the precedent has already been set that white space is or can be important for these operator type things. And I really like this because one of the annoying kind of gotchas with Haskell is that if you if you have some function that takes a number and you want to pass a negative number to it, you have to wrap it in parentheses, which is, I mean, honestly, kind of silly. And this language extension will mean you don't have to use parentheses anymore.

>> Yeah, I think, Yeah, I think this is gonna be good? I don't really think it could have a huge impact on current existing code. I do think moving forward that I think it will be really nice. I'm curious. With like some of the external tooling out there like HLint that says, Hey, we see you've got this language extension installed. Now you have these parens negative one. Those can go away now, like those kind of things may become possible, which would be, you know, a nice quality of life improvement. Yes, parens aren't terrible, but they're also kind of pointless for that situation. So it would be nice to have that I think this next one, we're gonna talk about those, actually, my favorite, because if you have a giant project loading GHCi and the giant project is tough unless you manually set the prompt to something else So this is saying the GHC prompt will no longer list loaded modules. I imagine there's still gonna be some shortcut to get to them. If you need to see what's imported or what's in scope, all you can always just say, What's this? Is it there cool. It is. Let's use it. If not, let's import it and be able to use it then.

>> Yeah, So for those not in the know, this has been another kind of long time uh, paper cut of the Haskell REPL, where if you fire up GHCi it'll normally say prelude and then like a greater than sign. And that's where you type in your stuff. And if you import module like data dot map, then it will say prelude space data dot map and then your prompt, Um, And for us, when we start GHCi for our project at work, we have on the order of, like, 1000 to 2000 modules. So our prompt, if we don't customize it, has 1000 modules, all all of their names there and then the little greater than sign. And then we type in whatever. So that's completely useless to us and takes up a ton of screen space. And this change will make it so that we don't have to customize our prompt anymore. It'll just do kind of what it probably should have always done in the first place.

>> Yeah, because, I mean, if you have everything listed, you could write a function, and by the time you hit enter, you're never going to see the output because it's gonna be wiped away by the new list of modules that the new prompt has

>> exactly

>> like it's rough. So we're excited about that. I think this one will be good overall. Long term for the Haskell community is making the haddock parsing more resilient, right? Because haddock deals with a lot of documentation, right?

>> Yes. So there's a lot of things kind of balled up in this, um, part of the change log, and some people may not have run into these problems, but I've run into them and they're really annoying. So with haddock, your comments become more important, right? Because your documentation lives in your comments. And haddock has certain things that are special that it cares about. So the most important one that most people are probably already familiar with is starting a comment with the vertical pipe. So if you do dash dash pipe, that means okay, I'm starting a documentation comment here. This will be attached to the function or type or whatever and then rendered when I run haddock. Um, there are other things that are important, like dash dash star and that one I mention because I run into this frequently, where a project will build just fine when I'm not producing any documentation and then When I try to build the documentation, it will crash, like, fail to compile. Because I have a comment somewhere that says, like Dash Dash, star, star star, important star, star star, You know, don't do this. And Haddock's like, Hey, I tried to, you know, interpret this as some special markup for myself, and I wasn't able to. And you know, I'm thinking, Why did you do that? Haddock. That's silly. Um, but yeah. So with GHC 9, it will be more resilient to these, so it won't crash. I think it will instead produce a warning so that you can realize like, Oh, this is ambiguous. If this is meant to be parsed by haddock or not,

>> that sounds helpful. Like that would be really frustrating. Very much my code works. And then you're like, Wait, what now? I'm building documentation. What happened?

>> Yeah, and many people don't build documentation themselves. So this problem gets even worse because you can have a project that builds perfectly fine for yourself, and then you release it and upload it to Hackage. And somebody complains like, Hey, you don't have any documentation on Hackage like, Yeah, I wrote documentation for everything, and it's because oh, Haddock failed to build. Um, so it'll actually be a little while until Haddock uses GHC 9. Excuse me. Hackage uses GHC 9, but when it does, we can look forward to this being a little more resilient.

>> That's good. Yeah. Speaking of you know, nightlies and LTS and Stackage. You know, we got a little while probably before that's coming out next couple of weeks.

>> Yeah, I saw a tweet. I forget who it was from one of the Stackage maintainers announcing that, you know, the nightlies and LTS are using GHC 8.10.4. And they're looking to use GHC 9 quickly on the nightlies. But I think a lot of packages they're going to get booted out because either they have version constraints that maybe just need to be relaxed or something changed in, You know, the GHCi, uh the bits of GHC that they use that needs to be changed to support it. Um, but yeah, I just wanted to wrap up with GHC 9. So there are many, many more things in the change log. It was hard to pick kind of the big ticket things that we should talk about because there's so many, Um there's a lot of bug fixes. There's a lot of performance improvements. Both when it comes to how quickly GHC compiles your code, but also with the code that GHC produces, it may run faster as well. So GHC 9 is just like an amazing release. Very excited for so many things in it.

>> Yeah, that's awesome, I mean You always expect, you know, quote unquote performance enhancements with any release of anything, you know, you get a new iPhone, your android phone, latest new processor like all those things. So that's you know, that's exciting because I think GHC needed that, um, you know, And they could do this with such a big release that has so many other enhancements as well.

>> Yeah, and I wanted to call that out because I know some people are concerned that if GHC focuses on these fancy new type system enhancements like linear types than maybe the more mundane or boring like quality of life improvements aren't gonna happen. Or even compiler performance may get worse as a result. But that is not the case, at least for this release. So kudos to the GHC team. They're doing amazing work. It's just again. Great release.

>> Yeah, I know. I'm really hoping we can get to it soon, but some of our tooling, you know, we're just tightly coupled. GHC versions Weeder, Brittany. Those guys just kind of make us have to slow down for all the new hotness, because we've gotta wait for it to support it had worked through all of its transitions.

>> Yeah, and we've talked on this show before about HLS, which some of us use and is also tightly coupled to the GHC version. So, yeah, the tooling side leaves maybe a little bit to be desired. But it also encourages you to use tooling that isn't tightly coupled to GHC in that way.

>> Yeah, that's true. Maybe she could takes, um, more enhancements in the tooling realm. I don't know.

>> Yeah, yeah, they definitely have their work cut out for them, but it would be excellent from our point of view if they could roll in some of these projects to GHC itself. So, like Weeder, for instance, Onley relies on the HIE files that GHC now produces, rather than having to interact with the GHC API So it's a little less coupled. Um, and then, you know, kind of like blue sky. It would be amazing if GHC had a formatter built in, and then we wouldn't need to use Brittany. But that may be a bridge too far.

>> We can always hope and dream, right?

>> Yeah, exactly um. But I think we had one last thing to talk about today, which is kind of related to the GHC 9 release. There's a new package put together by Tweag, uh, called linear-base. And this is like a replacement for the base library. So kind of, ah, standard library, so to speak, specifically for linear types. Um, And like I mentioned with linear types, I am not an authority here. I'll encourage you to go read the blog post where they announced this. Um, but the long and short of it is that in order to effectively work with linear types, you need a lot of common utilities to have linear versions, and that's what linear base provides. And it also provides many other things that aren't provided by the base library, like, um, efficient arrays, vectors, hash maps, sets. So things that you can get from other libraries, like array and vector and containers and unordered containers. But they're all in one library now. Um, and it also has even more stuff, like has a streaming abstraction built in, so think, like conduit or pipes. And it also has lenses and optics, like the lens library or the optics library on. But I think they're looking to add even more stuff to it. So it seems to be a surprisingly well featured standard library, considering how new all of this stuff is.

>> Yeah, that's awesome. Yeah. And if you're looking for the blog post, it will be in the show notes as well.

>> Mm. Or go check issue 250 of the newsletter and go sign up while you're at it.

>> Wow. We're at 250 man? That's awesome.

>> Yeah.

>> 250.

>> Been doing it a while. Um, but yeah, Like I said, I think those were the main highlights that we wanted to touch on for GHC and related stuff going on over the past couple weeks. Um, Cam did you have anything else that you wanted to remark on?

>> No, I think I'm excited about GHC 9 and seeing where it takes the Haskell community. And obviously all the other stuff we talked about is fantastic. So I'm really looking forward. to Yeah. Being a Haskell programmer. It's awesome.

>> Yeah, sure is. We're gonna have to learn more about linear types, so we'll see how that goes.

>> Yeah, maybe we can walk our listeners through it once we've learned we could just maybe here at work, you know, have some people figure out what linear types are and teach us.

>> Mm. Yeah. We may need to have some of our Haskell wizards on the engineering team teach us how it works.

>> I know, they're pretty excited about it, So yeah, that'll be good. No, Maybe have them. Come on. The podcast. Try to get Zach on the podcast today, but he wasn't quite ready, so that's okay, but maybe next time.

>> One of these days we'll convince him, but yeah, I think that will do it for us. Thank you for listening to the Haskell weekly podcast. I have been your host, Taylor Fausak, and the other voice you heard today was Cameron Gera. If you'd like to find out more about Haskell weekly, you can check out our website Haskell weekly dot news. If you like the show, please rate and review us on apple podcasts. And if you have any feedback you'd like to give to us, just tweet us at Haskell Weekly

>> and Haskell Weekly is brought to you by ITProTV an ACI learning company and our employer. They would like to offer you 30% off your subscription by using promo code Haskell Weekly 30 at check Out. That does it for us. Good. Sir. Taylor, I really like using that name today.

>> It sure does. So, yeah. Thank you for joining us on the Haskell Weekly podcast. And we'll see you hopefully next week.

>> See you next week.

>> Bye

>> Peace