Haskell Weekly

>> Hello and welcome to the Haskell weekly podcast. I'm your host, Taylor Fausak. I'm the lead engineer at I.T. Pro T.V.. With me today is one of the engineers on my team. Cameron Gera. Thanks for joining me today, Cam.

>> Thanks for having me, Taylor. I'm excited to hang out. Talk about some Haskell.

>> Yeah, it's all set to be a good day for podcasting.

>> Oh, yeah? Well, it's a great day in October and you know, as I love to say, it's Hacktoberfest. We've got one week left to contribute. Four pull requests to public repositories. So go check it out. Get a free T shirt. Sign up. It's awesome. The link will be in the show notes and specifically one that you know will help the Haskell community and build the Haskell community learn for Haskell, which is put up by Kowainik to allow you to learn some of the mechanics of Haskell and also do some problem solving in Haskell. So get some real world experience, so please, please, please go check that out. If you haven't, you've got one week left. It's gonna be awesome. But enough about Hacktoberfest because that's the one bit I've got at this point. What's what are we talking about today? What's what's going on? What does the idea of X G.H.C. 2021 excite you, man?

>> It does. And that's exactly what we're gonna be talking about today. So there was a reddit post over the past week from one of the members of the G.H.C. steering Committee and he was polling the community, asking them if they were interested in something that he was calling G.H.C. 2021. And I think the community was interested because there were something like 200 comments on this thread, which is pretty big for our little corner of the reddit sphere

>> dang. That sounds like it got some traction, you know? And it seems extreme to me because it's got the X in front of it, because that that's the language extension. But, you know, I thought that was pretty cool to see.

>> Yeah, I like calling those. Ah, that's the extreme version of Haskell Haskell X.

>> Yeah. I mean, there's extreme programming so extreme Haskell sounds good to me. Well, and something that came out of this, you know, Reddit thread was actually a proposal for this. And so, you know, I think that's something else we'll be talking about today as well. Kind of brief overview of what's kind of going on. What is G.H.C. 2021? Why do we need it? Stuff like that. So I'm really looking forward to kind of diving in today and really talking about stuff I really haven't had to worry about. Um, as an application developer, language extensions, which this is kind of in motivation of are kind of behind the scenes for me and what I've done in my Haskell experience. But Taylor for you, I think you've got a little more experience with language extensions. What they what they are and how they've progressed in the language of Haskell over time.

>> Yeah, So I have some experience as an application developer here. It I.T. pro T.V. and previously at Freckle. But also, I maintain some open source libraries on Hackage as well, and I've seen this progression happen. Most of it happened before I even started programming Haskell. So it started way back in 1998 and there was a spec put out for the language of Haskell and it is just known as Haskell 98. So if you see that floating around the Web, it's talking about the 1998 version of the Haskell language report.

>> Wow. So you're saying I could have asked for Christmas when I was five years old for Haskell 98?

>> Yeah. And you would have got it,

>> man. I would have been so much better off if I would've learned Haskell when I was five.

>> I'm not so sure about that. But I like where your head's at.

>> Okay, fair enough. Well, you know, we all we all come to the world of programming in our own ways. I mine is very different from a lot of co workers and other people I know who have been programming since they were in their young teens. I've only been programming in my twenties, so that's a little bit of a difference. But anyways, back to Haskell 98.

>> So Haskell 98 specifies all kinds of things about the language itself and some libraries like the prelude and all the core libraries and stuff like that. And it turns out that as Haskell started being used both in academia and in industry and by hobbyists. There were some things discovered in the report that weren't quite ideal. So in 2010 people got together and produced a new version of the Haskell report, which is Haskell 2010. So again, if you see that floating around, that's what it means. The 2010 version of the Haskell language report Haskell, 2010 doesn't change a whole lot from Haskell 98 even though in that 12 year span, you know, G.H.C. did a ton of work. There were many other compilers that came and went like U.H.C. and hugs and a bunch of others that I'm forgetting right now. Um, but Haskell, 2010 was pretty conservative in what it changed last year. There was some interest in producing yet another version of the language report that would be called Haskell 2020. That didn't end up happening for a bunch of reasons.

>> I mean, it's 2020 so it's pretty on par, right? Yeah, nothing's going according to plan in 2020. So

>> exactly. Yeah, we we should have seen it in 2019. That this was a, harbinger of the things to come, but yeah, Haskell, 2020 unfortunately, didn't happen. But people are still interested in improving on the language report that came out in 2010 because lots of things have happened in Haskell and in particular. One thing that people are very excited about is rolling language extensions into the base language. So instead of having to enable a bunch of extensions at the top of your source file or put them as your default extensions for your package or application, they'll just be part of Haskell for everybody. And that's kind of what this X G.H.C. 2021 proposed flag is doing

>> right. It's taking us a step in that direction. At least

>> it's not a full blown report. It's not a new spec for Haskell, but it is saying this is a set of extensions that we think can be considered like the default set from here on out,

>> right, and these, you know, proposed language extensions, which I don't think they have quite wrinkled out every detail of which ones they're gonna include and stuff like that. But generally they're gonna go towards the UN controversial, relatively quote unquote mundane, harmless right harmless. That's much better word I think that allows us to kind of get used to these language extensions that we may not know about we may not ever have dealt with because Vanilla Haskell lets us get by with what we need to do.

>> Yeah, and to give an example of an extension that may be included with Haskell with G.H.C. 2021. Like you said, they haven't landed on a list of them. But one of the most popular extensions is overloaded strings. So in the same way that when you write a numeric literal, it could be an integer value or it could be a ratio or a float. Um, normally in Haskell, when you write a string, it can only be the string type in the prelude but overloaded strings. Let's it be text or a byte string or something else. Um, and this is an extremely popular extension. It's enabled by default and tons of places, and in the past three years running the Haskell survey, it's been the number one most requested default enabled extension for the, you know, next version of the Haskell report, Um, so that's a prime candidate for something that could be enabled by G.H.C. 2021. And it's a nice quality of life improvement that probably won't break any existing code. It might, but it's generally pretty conservative and doesn't really change. Doesn't introduce new type level shenanigans to the language. It doesn't change what things mean too much so that that's probably the type of thing that will be included.

>> So cool. Well, I think that's a really great step for the community. Get a holistic bunch of language extensions and and say, Hey, this is what people want This is going to be bundled up in this G.H.C. 2021 we'll let people enable that rather than having to list every extension or, you know, put the language pragma in the top of their source file. And there you go.

>> Yeah, and this is if you look at another community like rust. They have this concept of an edition where the rust compiler is adding new features incrementally. I forget what their release schedule is. I think it's every six weeks or something like that. They're adding new features all the time, but you can pick to stay with, like I think it's rust 2018. I'm not a rust developer, so I don't know what the editions are, but you can say this is the set of features that I want and that will stay stable through time. So this set of extensions is kind of the same idea where you're going to say, I want the recommended set of extensions as of 2021 then, you know, five years from now, maybe you're still using that set because it works for you. Or maybe new versions have come out. And you think, Yeah, I want to opt into that. one the 2023 or 2025 one

>> Right, So they let it be stable. I know there was something called Glasgow extensions that was, you know, something that we could enable. What didn't work about that?

>> Yeah, in the past. So for those not in the know G.H.C., the flagship Haskell compiler, stands for the glorious glasgow Haskell compiler, and it accepts a flag called glasgow extensions that enables a kind of recommended set of extensions. So This isn't new ground necessarily. But what's different is that Glasgow extensions could change through releases of G.H.C.. So I don't remember which version of G.H.C. it was that it came out. But let's say that you were on 7.6 and you upgraded 7.8. This glasgow extensions flag might mean something different between those two versions. In comparison, this x G.H.C. 2021 flag is going to be consistent the same through time,

>> right? So you can maybe iterate your version of G.H.C. 20x 202x. You're gonna have the same extensions, but you have to take that step in changing to a new version.

>> You opt into the new stuff

>> where this other one was just always changing with every new version of G.H.C., you could see how that could be really annoying for, you know, maintaining libraries, maintaining even an application. Large applications. It would be beyond frustrating because,

>> and especially frustrating for libraries. Because if you want to support multiple versions of G.H.C. and you want to use this flag because it's convenient, you'll end up supporting some different set of extensions for each version, which is super weird.

>> Yeah, well, I'm glad that they've come to say, All right, we need a set version, control of extensions, right? That's not gonna be you know changing with each version of G.H.C.. But what are some other benefits about maybe taking a step this way towards a grouped set of extensions being imported by this flag?

>> One benefit of this set of language extensions all being bundled together with G.H.C. 2021 is that you kind of get the best of both worlds when it comes to explicit versus implicit. One of the upsides of explicitly listing all of your language extensions in each source file is that all of the tooling can understand it. Anybody coming into that file to read it can know which headspace to get into. You know, if I load up a file and it's got 20 lines of language extensions at the top and I see stuff like type in type and functional dependencies and GADTs, then I'm like, Okay, I'm gonna be putting on my type level programming hat versus if I open up a file and I only see, uh, let's say overloaded strings. Then I say, Okay, this is probably gonna be pretty typical application level code, nothing too fancy going on.

>> And I think it also the current listing out every extension helps just that readability, too. Obviously that the headspace, all that kind of jazz, what's the other option? If you don't, you know, without this new proposed flag, what's the other option? And I think you touched on a little bit earlier. Could you kind of expand on what may be some of the benefits of that?

>> Absolutely. So the package description, for whatever thing you're working on, probably has a section in there of default extensions and those are language extensions. that're going to be enabled in every source file, regardless of if they're at the top of the file or not. And this is super convenient and great for applications where, like for us at I.T. Pro T.V., we can sit down as a team and have a discussion about Do we want to enable scoped type variables everywhere for our application and furthermore, we can, turn it on and see what happens? See if we get any weird bugs or weird errors or anything like that. It's very easy for us to talk about it and experiment with it. For libraries, it's a little bit different because when you turn on an extension by default, you're kind of selecting for a particular contributor or potential contributor to your project. You're saying that in order to work with this project, you probably need to understand these extensions that I'm turning on. And so naturally, library developers are a little more conservative when it comes to turning on default language extensions because they want as many people as possible to be able to contribute, which means keeping the bar to clear low. So, for instance, I really like the extension numeric underscores where you can put underscores in numbers to kind of break them up into, like, thousands groups. But I don't want to turn that on as a language extension in any libraries that I develop because it's just another bar to clear for somebody when they're looking at the source code saying, Wait a minute, I didn't know you could have underscores in numbers, What is this? And then they scroll up to the top of The file and they don't see an extension there, and I'm like, What am I reading here? This isn't the same language that I know, Um, and that's obviously an extreme example. People will probably be able to figure out what's going on, but it would be nice. If at the top, I could just say G.H.C. 2021 somebody could go there and read about all the things that turns on.

>> Yeah, I think that's great insight. And, you know, kind of weighing some of the benefits of, you know, the explicitness for versus implicitness versus, you know what? This proposed flag, I think that really allows us to kind of think about it, figure out what feels right to us. Um, and having some known set of extensions to reference Sounds like a nice place to be, because it gives you a good balance of implicit versus explicit and kind of meets in the middle there. Um alright, Taylor. So we've talked about this new flag proposal. What are some of the things that kind of go into a new proposal for G.H.C.? You know, you can use this one as an example, obviously, because it's right here. It kind of says hello. Here's how you you create a proposal for G.H.C.. What? What's going on here?

>> There is a repository called G.H.C. proposals, and that's where all these things end up. I think it was set up. I want to say a year or two ago, Maybe. Maybe it's older than that, but the I'm an outsider to this process. So I'm explaining what I have seen. I don't have any insight into this necessarily. But this repository is a place for people to open up a pull request that contains document describing some change They would like to make to G.H.C. or Haskell or, I mean, usually G.H.C.. It's called G.H.C. proposals, but sometimes they could be a little, uh, more far reaching than that. So taking this one as an example, it's saying, we want to introduce this new extension flag called G.H.C. 2021 when you enable this flag, this is what's going to happen, and it will turn on all of these extensions. Um, I don't have the proposal in front of me, so I couldn't tell you what the current set of extensions they're proposing is. But that's the gist of what's going on here. And then there's a normal, you know, GitHub comment thread attached to that where people are discussing the pros and cons. Should we do this? Should we not? Which extensions should be included? All that kind of stuff you might expect to see on a discussion of this.

>> Yeah, and I really appreciate that. There's obviously some sort of template when creating these G.H.C. proposals because it makes you answer these questions that you may have not thought about and, you know, specifically they talk about, you know, costs and drawbacks, which I think is valuable for someone who has this great idea to really think about it and figure out how that could impact the Haskell community as a whole. And so I think that their cost and drawbacks to kind of what we've talked about, like, kind of hides readability a little bit with their new flag. But at the same time, it still gives you a reference point of where to go toe Look for what's going on. And, you know, I think another drawback and this is just when you want to make any change is that there's gonna be some heated debate. Somebody's not gonna wanna be on board with this extension or with that extension, and I think it creates conversation, maybe heated debates, just depending on how you take it. And you know, if it's phone call, it's a little more personable where you know, if you're chatting over a Git repo and you're on this pull request making comments, you can get a little short sometimes, which I think can create a little bit more tension. But I think they're doing a good job with trying to be more conservative rather than just say, Yeah, let's bring all the extensions in, like, Alright, let's let's bring in the known set that's used by a vast majority and. I think they've also kind of talked about how this list gets curated, which I think it's nice that they kind of documented that as well. So you know, if you're interested, check out the show, notes the proposals. There so thank you for kind of jumping into that. I know I kind of threw off guard there with that question of like,

>> no problem happy to do it. And I also wanted to mention I said this earlier. But this is a question that I have included in the State of Haskell survey for the past three years, and I'll be including it this year as well. Um, it's not specific to G.H.C. 2021 but language extensions are, a, popular topic in the Haskell community. And in the survey, I ask if we were to produce a new version of the Haskell language report. Which extensions would you want to be enabled by default? So there is three years of data to look at their from the community of which things should be on by default. And, you know, clearly this is a slightly different discussion that than that exactly. But I think there is some cross pollination there,

>> right? So if you're the one who made this extension or this proposal get with Taylor, he's got some great data.

>> It's all out there. You don't need to collaborate with me, but wouldn't mind. Also, I wanted to point out that the name kind of implies that this is something that could happen every year. So it's not critically important that we get it exactly right on the first year because we could try a set and realize Wait a minute. This one probably shouldn't have been in there. So let's take it out next year, and this other one probably should have been in there. So let's add it and that hopefully will be a relatively easy process versus making a new version of the report

>> right, And I think it allows you to create a change log to like from year to year. What's what's changed? What's going on Before I decided, Oh, I wanna be on 2022 now And you know, they mentioned that in the proposal as well. So I think that's a nice benefit and definitely a good step in that direction. Obviously, we're not going to sit here and debate which one should be in because, you know, there's a lot out there. There's a lot of options, and for us when we have enabled language extensions, a, majority of the time it's been because of a library that requires said language extension. So I think as our our team grows at I.T. pro T.V., we've had more people come with other experience in Haskell. That says, Oh, what about this one? Which leads to that discussion you were talking about earlier, where we just kind of figure out, you know, is this something you want to try? Let's give it a shot. Let's give it a good old college try and see what happens. I think that's, you know, something they could do with this, too, is like, it's gonna be a discussion. They're going to come up with something to begin with, and they can iterate on it, as as need be.

>> Yeah, And that's a pretty easy discussion for us to have with eight people. So good luck to them having that discussion with the thousands of people involved in the Haskell community.

>> Good luck. Well, I think that's all we have to say on this one. I think it's been a good podcast. It's got to chat a little bit a little more, Uh, a theoretical conversation of, like, what should we do? What's this Gonna dio with a little concrete in there? So I appreciate that. Um, but yeah, I think I think that's gonna do it for us, right?

>> Yeah, that'll do it. Thank you for listening to the Haskell weekly podcast. I've been your host, Taylor Fausak, and with me was Cameron Gera. If you'd like to follow us on social media, our twitter handle is Haskell Weekly our Reddit user name Also Haskell Weekly our GitHub user name. You guessed it Haskell weekly. Our website, is Haskell weekly dot News.

>> And today's show is brought to you by I.T. Pro T.V., the e learning platform for I.T. professionals, also our employer. And they would love to extend an offer of 30% off on I.T. Pro T.V. membership. So the code will be a Haskell Weekly 30 or again that is Haskell Weekly 30 to get 30% off the lifetime of your subscription I.T. pro T.V.

>> Thanks so much for listening, and we'll see you next week bye

>> peace.