Bryce 0:00

This is going into the episode, though. All that's going into the episode.

Conor 0:03

Can't you just take like a hammer and hit it from the inside?

Bryce 0:07

You're gonna you're gonna cut you cut that 20 minutes of pure pattern price gold. You're gonna make me so sad. That was such great content. That was that was glorious.

Conor 0:29

Welcome to ADSP the podcast, episode 8, recorded on January 9th, 2021. My name is Connor, and on today's episode with my co-host Bryce, we're gonna be talking about names and the taka of stood move only function.

Bryce 0:50

So uh what's the name of this episode?

Conor 0:54

Probably it's just gonna be naming with an exclamation mark. Or do you suggest something different? Well let's yeah, let's but let's bike shit on the name of this episode.

Bryce 1:03

I thought we were gonna call it what's the title. JF suggested that on Twitter, and I thought that was a good a good idea.

Conor 1:10

What's the title?

Bryce 1:11

Yeah, what's the title? Should be the title. I think it's so clever. I mean, we could call it like what's the title and then in parentheses naming. Although you know I hate I hate sub subtitles in uh talks and uh and and things. But pr pro a pro tip to anybody that's submitting a conference talk to like CPPCon or C now or anything in the C world, don't give your talk or just anybody who's giving a conference talk in general, don't give your talk a subtitle. Like, and by a subtitle I mean like don't have your talk title be like blah blah blah colon blah blah blah blah blah blah blah blah blah. I say this so frequently.

Conor 1:55

Why does that so I was trying to think like what you meant, and that's what I was thinking is that it's a colon. So like if I had to called my first talk algorithm intuition, colon, you know, how to think about algorithms better. Uh what so I I also I don't think I've ever put a colon in one of my talk titles. But my question is, why do you uh why why are you opposed or why is it less preferable?

Bryce 2:19

Let's go back to that uh to the title you just came up with for your algorithm intuition talk. Um so you said what? Algorithm intuition, colon, what was the rest of it?

Conor 2:29

You know, uh I can't even remember how to how to think better about algorithms, something like that.

Bryce 2:34

Okay. That second part of that talk title is just noise. Like, what what does that tell you that the first part did not tell you?

Conor 2:45

Well, I mean that's probably a bad example though, because I'm sure there are some talks that uh you know that do actually have extra information in the in the second partition after the colon.

Bryce 2:56

That might be, but it it is o that this pattern of having a primary title and then a secondary title, it is almost always a trap. So one way that it's a trap frequently is um people just use it as a crutch to give a talk a much longer title than it needs to have. Um your title should be like two or three or four words, maybe a few more than that. But people will will people who want to give their talk a really long title, they'll end up in this subtitle, you know, paradigm. Um in general, I don't like long talk titles. I think it should be like short and catchy. The second reason that this pattern is a trap is frequently uh you'll see something like words that don't make sense without context, colon, the context that makes them make sense. So it in this um form of uh the talk with subtitle, you've picked a title, a primary title for your talk, but then you've decided that the primary title for your talk was not clear about what the talk was. And so you've needed to explain the title in the rest of the title. Uh and that's just like, come on. Like if your talk title needs an explanation, then who's gonna come to your talk? When you're giving a conference talk, people people worry about you know making their slides, they worry about you know having a good abstract. The majority of conference attendees decide which talks to go to based solely on the title. The majority of people that are gonna watch a YouTube video of a talk decide that solely on the title. Like the name really matters. And so I I think you should pick a short, concise title for your talks. And uh I guess I guess that brings us to our to our main subject, which is uh we're gonna talk about names today. And we've been afraid to do this episode because um We have? I've been afraid to do this episode because I think this is this episode is gonna be like one of our like golden hits, but I I've been like our this topic is gonna be one of our golden hits, but I I wanted to save it until we got like really good at this podcasting thing.

Conor 5:21

Well, you think we're really good? No.

Bryce 5:24

Um no, I just we just ran out of things to talk about.

Conor 5:30

That's not true. We have a stack of topics. I uh we you just suggested it and I was like, yeah, it sounds uh it sounds great. I love talking about well just to go back to the titles of talks, I I do agree that I uh I tend to try and choose shorter titles that are like catchy and that like intrigues people enough to either just yeah, click on the YouTube video, or if you're you know scrolling through the program, I you know, uh in contrary in contrast to what uh Bryce has said, do actually read the abstracts when trying to decide between talks. Um uh but I will say I, you know, like you know, I have a proposed talk that I'll give probably in 2022 because looks like everything's gonna be online this year, um, called The Twin Algorithms, which is it's catchy enough, hopefully that people are interested. Maybe they'll read the abstract. Um but on the other hand, I also just gave a talk that was entitled in some order, I always get the permutation wrong, but uh C concepts versus Rust traits versus Swift Protocols versus Haskell type classes, because I couldn't figure out like a catchy, like I could have called it um like you know parametric polymorphism across languages, um, but I think that's like a worse title, and it's also sort of a misnomer because C concepts are superficially they give you support for parametric polymorphism.

Bryce 6:47

It also sounds like a snooze fest.

Conor 6:49

Yeah. But like if you put Rust versus C versus Swift versus Haskell, there's a number of people that find that kind of uh language comparison. So I guess my question is I agree, that's a very long title, longer than I'd like it to be. What would what would your advice be to pass Connor on naming that? Would it be to try try harder, think of uh think of something?

Bryce 7:11

Um I'm not sure you you really like the versus um uh talks. You've given a a number of talks, or you you like the construction of a talk title that's like X versus Y versus Z. Um well I don't think I would ever use that construction. Um uh I think for you and for the type of talk that you give, um it's sort of like part of your brand. Because you you often give talks that are comparative studies, um, and your talks often incorporate um uh a lot of background in prior art. In fact, I I would say that that's almost like a key element of the way that you give a talk. If you look at the first talk that you the first big talk you gave at a conference, Algorithm Intuition, um uh which uh won a pile of awards at C now 2019.

Conor 8:15

Our listeners know that you don't need to keep on bringing it up.

Bryce 8:18

And I I have a great picture which I will retweet of what Connor and I were sitting at down at the awards, uh and I had been telling Connor, I've been telling Connor all week you're gonna win like all the awards. And he did, and just I have this picture as he won like the third or fourth one, and he's just he's just losing it. Um but but if you look at that talk, you know, at the start of that talk, you do something that um I I I don't see that frequently, or I hadn't seen that frequently up until you gave that talk, where you started your talk with a series of clips from other people's talks. Um and then you talked about, you know, uh some of the core C standard library algorithms, and you talked about them in comparison with other languages, and you looked at, well, you know, this is how they'd be structured in these other languages, and then from that you extrapolated, well, this is really how these uh algorithms should be structured in C. And if you if you have all this history in this background, you realize, oh, maybe we may maybe we should have designed uh this algorithm's API a little bit differently. Um but one of the key elements of that talk was uh this uh this use sort of you're sort of like a DJ remixing some folks others attracts uh uh into yours, where you use these clips from other people's talks, you used this um uh these patterns and and and this uh uh uh the history from other languages to sort of inform um uh your analysis of C. And so I think that's like a very core to your brand that that you you don't look at things in isolation, that you do a ton of research and that you draw upon you know what you learn in your research when giving your talk. And so thus I I think the you know X versus Y sort of talk makes a lot of sense for you because you are often looking at and comparing and contrasting these different things. That's that's one of your strengths.

Conor 10:31

Yeah, it's uh so I guess yeah, I guess the the takeaway there is no know your style and like tailor your titles to your style. Yeah. Um it's interesting because I think it was at the we we briefly mentioned the Belfast dinner of of 2019 that we both have fond memories of, and David Senkel was one of the individuals at that dinner, and he um was trying to come up with like a name for the type of talk. Um uh because some people some people were referring to it as like a meta talk, that it's like it's a talk mentioning other talks. Um, but but David was not satisfied with that. So I think if I recall correctly, what he came up with is he said, You're a a new media historian um with respect to like programming languages and uh it's not just conference talks, but podcasts and and you know papers uh more recently. But yeah, I I guess so. It works if it if it's uh if it syncs with your brand. Um but anyways, we should we should get back to naming uh instead of just talking about talking about.

Bryce 11:35

I think that's like a good branding for you. I don't I don't know if if if you're if it's new media historian or like programming anthropologist, but like something in that in that uh in that area. Um uh you definitely you use the same comparative analysis techniques that are common to um uh a lot of fields of history and anthropology.

Conor 12:02

Um but you just you use it in tech, which well, so while we're on this topic, I this was actually one of the things I wanted to mention. I tweeted about this, um, but it's uh for for those of you that are, you know, when I listen to podcasts, every once in a while there's a guest or a host that says, I'm I'm a programming language enthusiast and I consider myself like a programming language historian. Um for those of you that uh identify with that statement, uh I just stumbled across a talk um yesterday uh that was actually linked to me on Thursday night while I was attending the Denver C meetup. Um it was I got linked a talk by an individual uh by the name of Galad Braca, I think I'm pronouncing that correct, and he recently gave a talk called The Ray of Hope, which is on this new programming, APL-inspired programming language called Shaperink. Um, and then at the end of that talk, he links to a talk called A Slice of Programming Language History, which only has like a thousand views on YouTube because it's posted on his private YouTube channel. Um, but it specifically looks at it your favorite COBOL gets mentioned at the beginning, Fortran. Um it really looks at like the 50s and the early 60s and focuses mostly on APL and why it's uh a beautiful language and misunderstood. But anyways, I'll link it in the show notes. Um and I just I I've been on this APL kick for now like over a year, and I was super surprised that I hadn't stumbled across this yet because it's a gem of a talk. Um and that's there's another talk, I'm not even gonna remember the name of it, but I'll link it as well. And this this is sort of super on on topic with respect to names. It was a strange loop talk, I think, given in like 2013 or 14, um, which is a talk about like Fortran, uh COBOL, Lisp, um, and then I think Algol was the fourth one. It focuses on four really early programming languages, and it is like a early history of programming languages talk. But the title of the talk, maybe I'll like I'll look it up later and insert it in post. The title of the talk was All of This Happened Before and It Will Happen Again by Mark Allen at Strange Loop 2014. But it it's completely obfuscates that it's a programming uh language history talk. It's like it's like the beginning of a quote, like on the something of something, dot dot dot. Um and just like browsing the Strange Loop like YouTube playlist. If if you had seen the title, you would have no idea what the talk was about. Um and it it's not I no offense to the the speaker because he's one of my favorite speakers. Um I believe his name's Mark, insert something. Uh maybe I'll fix that in post as well.

Bryce 14:34

He's one of my favorite speakers.

Conor 14:36

I can't remember he doesn't give uh he doesn't give talks very often anymore, so he he only has a handful of them. And even the ones um that he's given, some of them don't even have YouTube recordings, or they did at one point, but they've been removed. So I've I've clicked through the slides, um, but yeah, it's it's not the same thing. Anyways, yes, uh titles and names of your talks are important. Um but yes, let's let's get back to just naming in software software development in general. So what are your what are your thoughts? What are we talking about?

Bryce 15:06

That I wanted to talk about it this week is um uh one of my one of my jobs is I'm the chair of the C committee's library evolution group, which is basically the group responsible for the design of the standard the C standard library. And uh this week we hopefully closed um uh what has been a long and arduous saga in uh C naming. Um so there's in C we have um a series of std function. Yeah, std function. We have a series of function wrappers um that are either in the standard library or being put into the standard library. Um so std function is the one that exists today, which is um it's the type-erased holder for something that you can call. So it can hold a function pointer, it can hold a uh function object, um, etc. Um and the idea is that you like you can say, hey, I want a I want a std function with this particular signature, and it can abstract holding any of the types of things that are callable that have that signature. Um and so that you can make an interface where you can um uh pass in either a function pointer or a function object, etc., without having that interface be templated. Um and uh there's two new function wrappers of that family. There's one called function ref. Um fun uh std function is uh is an owning uh uh wrapper, so it owns the thing that you've you've given to it. Uh obviously for a function pointer, you can't really own a function pointer. Functions aren't uh top level uh entities in the C programming language, so um you can't uh you know um pass a function around as a as a variable, functions aren't objects in the language. Um uh but a function, a std function lets you take a function pointer and and give you back something that is actually an object. Um but it but it's owning, it owns the underlying thing. So if you pass a a function object of your own into a std function, then it will own a copy of that uh uh uh function that you passed in. A function object that you passed in. Um so function ref is a non-owning um uh uh form of std function when you have some existing uh function object or callable um uh that you want to pass into some interface, but you don't want to um uh make a copy of it or you don't want the the wrapper to own it. Um and then there's there's this other one, which it's basically an improved form of std function. Um we can't make the improvements to std function directly because that would be a breaking change and an ABI breaking change in particular, and we tend to not like making those, but there's a number of problems with std function. Um in particular, it doesn't work very well, or it doesn't work at all when you have a uh a callable thing that um uh is move only um or that is single shot. And so uh we th there's some other problems too, but that was the main problem we wanted to solve where you've got like some callable that you can just call once um and that is move only, it can't be copied. Um std function requires copyability, so we wanted to introduce a new form of std function that was uh uh for move only that would support move only things and had some other fixes. And we originally were gonna call it unique function, um a la unique pointer. Um but that name died in a fire because um people felt that it was not technically correct. Because while you can uniquely own a function object, um just as you know, a unique pointer is a unique it has is a uniquely owned handle to some you know dynamically allocated thing. Um and because unique unique pointers move only, it only allows one entity at a time to have ownership of it, which um makes it very simple to clean up when you're done with it. Um uh but uh you you can have that for a function object. You could have a unique function that just takes function objects and it uniquely owns them, but people argued that for function pointer, that doesn't make sense because again, functions aren't objects in C, and uh anybody could have that function pointer, and you can't really uniquely own a function pointer. So uh on those grounds the name unique function got axed because it seemed to suggest semantics um that uh it didn't actually have. In particular, it suggested semantics similar to unique pointer that it didn't actually have. Um so then we we moved on to a very curious name, which was any underbar invocable. Um so function was no longer a part of the name at all. And uh the reason that it was called any invocable is um in C ⁇ we've just intro recently introduced the idea of concepts. And Connor, can you maybe explain what concepts are in a way that will be understandable to folks who maybe aren't familiar with it in C.

Conor 20:51

Well, so the the once the once well, go watch my talk, Plug Plug, uh that was an introduction to those language facilities. Um but I mentioned this in the talk, and a couple people have told me that this is wrong, but this is my mental model uh for concepts. So like the comparison of sort of types to values, like a type defines um the values that your value can take. So an integer can represent, you know, integer numbers, 0, 1, 2, 3, float can represent uh you know uh numbers with fra fractional uh parts. And you know, the double versus the float, you know, it's 32 versus 64 bit defines the range. So your your type defines the values that your your type can assume. A concept is basically what a type is to a value, a concept is to a type. So it is a a a set of sort of types um uh that are defined by a concept. Um and so the main, or at least in my mind, the main thing that uh you can use this for in C is to constrain your generic functions. So if you've got a generic function that takes takes a type uh template uh Uh, you know, type T, um that is quote unquote unconstrained. And then if you add a concept to it, which there's different ways to spell that in C now and C20, uh, my favorite is to just uh if if you've got in your parameter list, you know, your generic type T and then lowercase t for the name of it, you can replace that uppercase t uh with an auto, and then before the auto put the concept. Um that's basically saying this generic function can only take types that conform to this concept. Um and this is called you know, adjacent things in other languages uh are called uh different names. So in in Rust they're called traits, in Swift they're called protocols, in Haskell they're called type classes, and they they vary from language to language, um, but this is the the general idea.

Bryce 22:47

Um what are they called in APL?

Conor 22:50

APL is a dynamically typed language. So um there is uh an individual, I believe, at Northeastern, his name's Justin Slepak, that's working on a language called Ramora, um, which is adding static types um to sort of a APL-like language that supports um uh you know rank polymorphism and the things that APL supports. But yeah, uh APL on its own is dynamically typed, so I don't think I don't think with without static types, yeah, I don't think you can have uh sort of a generics facility, concept-like facility.

Bryce 23:22

Um so um in C the name for the concept uh uh uh for things that can be called um like a as if by function call is um uh invocable. So the invocable concept, any any type that um can be called or can be invoked um with the you know std invoke function, uh which is a function helper for uh uh invoking invocable things, um, satisfies the invocable concept. And so uh so that's the invocable part of the any invocable name. The any part comes from uh uh the type erase nature of this thing. Um so uh as I mentioned before, you know, that's one of the key things about std function and also about function ref when I make a the type of a std function object is be like std function um uh with for like a function that returns an int and takes an int. Um that might be the type of a std function. Um that stdd function could store you know some function object type. Um it could store some function pointer, um, could store a different function object type. Um and so unlike just like a templated interface that might uh uh take something of the invocable concept, a std function has to type erase the underlying thing. Um it just takes the signature as a parameter, not the type of the thing. Um and uh in C, we have a facility called stdany, which is just like a generic uh type erasure mechanism. And so the idea was, well, okay, this is a this is a type erased function, uh type erased wrapper for things that are invocable, so we'll call it any underbar invocable. Um and uh there are some that that felt that this should be a general pattern that um we're going to have places in the standard library where we want to have a type erased a wrapper for a particular concept. Um uh the other one that's sort of in the works is any executor, uh, a type eraser for um the executor um concept. Um you might imagine um an any underbar allocator. We already have some type eraser facilities for allocators in the standard library, but perhaps if we were following this naming scheme, we would have called those facilities any allocator or any memory resource. Um maybe there's some place where you'd want to have any iterator. Um so that was the basic idea of this naming pattern. Um and it's probably worth mentioning how the library evolution group used to select names for things. Um uh the bike shedding process, although we try to not use that term. So the the way we used to operate was anytime objections to a name would come up, there would sort of be some hand waving saying, well, we'll settle the name later, just pretend the name's a placeholder for now, etc. etc. And then the way that we would settle um uh upon a name was we'd pull up a blank, you know, text editor, and um the chair would say to the room, all right, suggest some names. There are no bad ideas, just suggest some names. And um that is how we got to some quite amusing suggestions for the name of this new uh type-erased uh uh function wrapper. If I recall, we did this particular bike shedding on like a Friday afternoon at the after the the end of a week of uh meetings, and so some of us might have been a little bit tired and giddy, but I recall I think Mo Funk was on the list of potential names for this. Um I think there were a few others like that. And then what we do is we uh we um tell people vote for all of the names that you like, and then we do some amount of runoffs among the names that we like and eventually hopefully settle upon a candidate. Um more recently, we've decided to establish uh uh some new naming policies. And the the new policies are essentially if we're gonna um uh have a debate over the names of things, we need to do research first. So all of the names that we consider, there should be some written up document that has research the name and that has some justification for why it's a good name and uh why other names might not be good names. Um and in this new process, a lot of this came out of the the um the the naming of this facility. Um and uh so we settled on any invocable about a year ago, and I think it m I think some of us realized at the time that that name was not not super great. And one of the problems with that name uh was consistency.

Conor 29:07

Um otherwise known as symmetry for for me, I personally.

Bryce 29:12

Yes, otherwise known as symmetry. So if we're gonna have a thing in the standard called std function and a thing called std function ref, it's a little bit confusing if the modern version of std function is called std any invocable. Now some argued, well, okay, but we're trying to establish this new pattern. Um but at the end of the day, like i it that was gonna be a little bit inconsistent, and it was also not clear if people would understand, like just regular lay programmers would understand what uh any invocable is. If you don't know what concepts are, if you're not particularly interested in learning, um that name could be quite confusing. It makes a lot of sense if you if you know about concepts and if you know the background, sure. Um and one one thing to understand about C standardization, uh there are two different types of legal systems. Um uh there is what's called um the French system, where um the law of the land is all specifically codified um in a fairly large you know body of of uh laws um and that is what is enforced. Um and then there's the British system where you have a much smaller set of laws and guidelines uh for how those laws should be interpreted. Um but you have a very large body of um precedent, of case law as it's called. Um so the law often depends on what courts decided the law to be in the past. Um and so you often have to look at you know the precedents, the prior art, etc. Um, the C programming language has a British legal system. Um uh I have been asked at some points in time to, you know, hey, can you link me to the C standard library, you know, comprehensive design guide guidelines? Well, they don't they don't necessarily exist. We've written down some of those design guidelines, we continue to try to write some of those down, but we'll never be able to fully codify everything that comp that comprises C standard library design. But that doesn't mean that it's not documented somewhere, it's documented in the standard library, in the decisions we've made in the past, um, in the existing facilities that we have. Uh and so often when we're making a decision about what to do in the standard library, we want to look at what have we done in the past and what will be consistent with what we've done in the past. And I think that's generally a good principle to follow, um, that you should try to be consistent with yourself when it makes sense. And if you're gonna be inconsistent with yourself, you should know about that and you should be inconsistent willfully, right? If you're gonna break from existing convention, you should do that and you should do that very clearly, and you should try to set a new precedent.

Conor 32:40

So, what's the end of the story? What uh what happened in the last week?

Bryce 32:44

Um, okay, so um we we went back to revisit uh the name of this facility in the past uh month or so, and um we settled upon that we wanted function to be in the name of it, not invocable. Um and we we had some very interesting discussions about sort of the nature of names. Um one of the questions that came up was should we name this facility for what it is or for what it holds? And that's a very like fundamental and interesting indeed question. Um so what what people meant like that, you know, some people said, well, you know, the name any invocable it suggests that um it can hold any possible invocable thing. Um and it's not necessarily the case. Um there was a series of names suggested that were something like move only function, move only, or movable um function, etc. Um and people questioned, well, is that really the right the right thing? Should we really uh is that is that the the key property that we want to document um uh about this? Um and there were there were also questions about um uh whet whether whether the name needed to reflect the properties again, I think it all comes back to whether to whether the name needed to reflect the properties of the stored invocable or of the wrapper itself. Like the any invocable name, that use of that any prefix, it documents that the that the wrapper uses type erasure. Is that important? Do you need to know that? Um and there were some suggestion that maybe we should call it any callable or any callback. And people say, well, we well, maybe we should put callback in the name because that's what it's most likely going to be used for, is for callbacks. Should should the name of this thing reflect how it's going to be used, what what we think its intended purpose was? Well, no. Some people argued that would be unwise because while we might think today that that's what its intended purpose is, that's not necessarily how it's going to be used. And other people may have different intended purposes. So I I think uh I think a lot of the discussion around this um uh particular issue is pertinent to any discussion about naming. When you're picking a name, are you naming the thing like what what attributes of the thing do you want to reflect in the name? Um do you want the name to reflect uh the intended use cases of the thing, or do you want it to reflect what it does? Um and you know, in the in the case of something like a wrapper like this, like should should the name reflect what it contains or what it is? Or and should it reflect the properties of what it contains or what it is? Um I don't have answers to any of these questions, but um I I think people I I spend a lot of my time at work in lengthy debates with people about names. Um and some people I think believe that names are maybe superficial, that it's just you know it's not as important as the semantics or syntax, that it's just like an implementation detail and or or not an implementation detail, but it's just like a minor detail that that we can figure out later, or that it's not that important. And why is Bryce giving us such a hard time about names? Uh and the reason is that names are very important. Um uh in name, a good name will affect how the thing is used and whether it's used at all. Um and not only that, but you also have to ensure that names are consistent with uh similar related and related facilities. Um and then there's a whole nother um facet to naming, which is um avoiding um uh connotations. Um so for any name or brand, um there is you have some denotive meaning, your the primary intended meaning of the thing. But you also have to think about what are the connotations, what are other meanings that might be associated with this term? Uh I come from the concurrency world. One of the big problems in that world is when people use the terms tasks or threads. You know, you there was some some suggestion that we should name C20's J thread, um, which was an improved form of the C11's std thread. Somebody suggested maybe we should call it task thread, because that's what it's for. It's if you're if you want some higher level thread construct to launch a task. And I was like, are you kidding? The terms task and thread have a different meaning in like every parallel programming framework and like in every different parallel programming uh paradigm. Like they're the two most overloaded terms in this field. You can't just stick them together. You have to think about is this part of the name gonna have secondary meanings to to anybody? And if so, then you should probably just avoid it. Even if it's a great name, it's better to have an unambiguous name.

Conor 38:50

So, yeah, one there's a couple things I wanna I wanna uh mention. So one of them is an APL anecdote that you might be thinking, oh, how does APL tie into this? Well, um Ken Iverson, the creator of the language, uh cared extremely deeply about um meaning and words. So much so that he had a copy of, I believe it was like some Oxford dictionary, and he gifted it to like many people. And it was like uh getting the Oxford dictionary from Ken Iverson was like a very um it's it was a very meaningful gift. Um because he would spend time like reading the dictionary trying to find words that were evocative, um, that evoked like the essence of what um you were doing. So an example is that in APL, uh the comma, um, the dyadic meaning is catenate, um, which is interesting because most languages call it concatenate or concat. Um, but uh there's there's a trivia that if you actually look back to like the 60s when it was named, um catenate was used uh just as widely as concatenate. It might even it might have even been the preferred word. And then at a certain point in the 70s, concatenate took off as like the primary uh uh preferred word over catenate. Um uh but so that's the dyadic meaning of comma. But the monadic meaning, the one that just takes a single argument is ravel. Um so that's R-A-V-E-L. And what that does is basically um given your n-dimensional uh array, it flattens that into basically just like a one-rank uh array, which is just like a std vector, a std list, so a flat list of numbers. Um and uh the reason he chose ravel was because the comma looks a little bit like a needle for like you know uh sewing. And once you see that, you won't unsee that. And the way he described it is when you think of the word ravel, think of a spool of thread unwinding. So you've got like a spool of thread where you know it's all wound up around it, and then if you pull on that thread and unravel, uh you basically like are taking what was cylindrical and then putting it into a line. Um and it's so it's it's this visualization of this imagery of like taking a spool of thread and sort of like pulling it out, and you get one number at a time. Um and I read so I read a blog or an article uh that talked about this, and I thought it's it's brilliant. And there's multiple times where um you know people can point at IOTA. I haven't heard the story by uh um, you know, why that got chosen, uh, and and many people have said that wasn't the the best name. Um but like in APL a lot of the names, like a lot of thought um was put into it because yeah, names, good names um can be extremely evocative, and like you can almost well, I guess Ravel, you sort of needed a story for that one. So maybe that's a bad example as well. Anyways, there was a second thing I was gonna say, but I can't remember at this point. Um yeah, threading. You were saying threading was overloaded. And then yeah, the perfect you were saying in the context of like parallelism and concurrency, but even outside of that, like uh I I'm not sure if it's been mentioned on this podcast before, but yeah, in in Lisps uh like Clojure and Racket, uh, they have a threading macro, um, which has nothing to do with parallelism or concurrency. Um and so yeah, that that's like probably my biggest like um motivator or like uh driving principle in naming things is symmetry. Um so like when it comes to std function, std function ref, and then what are we gonna name the next thing? Um if it belongs to that family, it should have a certain amount of symmetry with that family, which is why I like you know, insert underscore function or something that's prefixed. And and it's not just symmetry within a language, but it's symmetry across languages. And that's where we'll have to end our first part of our two part, potentially three part naming episode series. Thanks for listening and have a great day.