Algorithms + Data Structures = Programs - Episode 8: What's the title? (Naming - Part 1)

Episode Date: January 15, 2021

In this episode, Bryce and Conor talk about naming and the std::move_only_function saga.Date Recorded: 2021-01-09Date Released: 2021-01-15Algorithm Intuition - C++NowConcepts vs Typeclasses vs Traits vs Protocols - Meeting C++ 2020Tweet about Gilad Bracha TalkGilad Bracha - A Slice Through the History of Programming LanguagesGilad Bracha - A Ray of Hope: Array Programming for the 21st CenturyMark Allen - All of this has happened before, and it will all happen againstd::functionfunction_ref Proposalany_invocable ProposalC++20 ConceptsJustin Slepak’s Remora Languagestd::anyIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

this is going into the episode though all that's going into the episode can't you just take like a hammer and hit it from the inside you're gonna you're gonna cut you're gonna cut that 20 minutes of pure connor and bryce gold you're gonna make me so sad that was such great content that was that was glorious 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 going to be talking about names and the saga of stood move only function so uh what's the name of this episode probably it's just going to be naming with an exclamation mark or do you suggest something different well let's yeah let's let's bike shed on the name of this episode i thought we were going to call it What's the Title? JF suggested that on Twitter, and I thought that was a good idea.

What's the Title? 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 subtitles in talks and things. 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. 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 see this so frequently. 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 called my first talk algorithm intuition,

colon, you know, how to think about algorithms better. So I also, I don't think I've ever put a colon in one of my talk titles. But my question is, why are you opposed or why is it less preferable? Let's go back to that, to the title you just came up with for your algorithm intuition talk. So you said what? Algorithm intuition, colon, what was the rest of it? You know, I can't even remember. How to think better about algorithms, something like that. Okay. That second part of that talk title is just noise. Like, what does that tell you that the first part did not tell you? Well, I mean, that's probably a bad example, though, because I'm sure there are some talks that, you know, that do actually have extra information in the second partition after the colon.

That might be, but 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 people just use it as a crutch to give a talk a much longer title than it needs to have. Your title should be like two or three or four words, maybe a few more than that. But people who want to give their talk a really long title, they'll end up in this subtitle paradigm. In general, I don't like long talk titles. I think it should be short and catchy. The second reason that this pattern is a trap is frequently you'll see something like words that don't make sense without context, colon, the context that makes them make sense. So in this form of 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. And that's just like, come on, like if your talk title needs an explanation, then who's going to come to your talk? When you're giving a conference talk, 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 going to watch a YouTube video of a talk decide that solely on the title. Like, the name really matters. And so I think you should pick a short,

concise title for your talks. And I guess that brings us to our main subject, which is we're going to talk about names today. And we've been afraid to do this episode because... We have? I've been afraid to do this episode because i think this is this episode is going to be like one of our like golden hits but i i've been like our this topic is going to be one of our golden hits but i i wanted to save it until we got like really good at this podcasting thing what you think we're really good now um no i just we just ran out of things to talk about that's not true we have a stack of topics i uh 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 click on the YouTube video or if you're scrolling through the program. I, you know, in contrast to what Bryce has said, do actually read the abstracts when trying to decide between talks. But I will say, you know, I have a proposed talk that I'll give probably in 2022 because looks like everything's going to be online this year called the twin algorithms which is it's catchy enough hopefully that people are interested maybe they'll read the abstract but on the other hand I also just gave a talk that was entitled in some order I always get the permutation wrong but 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 like, you know, parametric polymorphism across languages. 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. It also sounds like a snooze fest. Yeah, yeah. But like if you put Rust versus C++ versus Swift versus Haskell, there's a number of people that find that kind of 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 your advice be to past connor on naming that would it be to try try harder think of uh think of something um

i'm not sure what do i call you you really like the verses um talks you've given a number of or you like the construction of a talk title that's like x versus y versus z um yeah uh so well 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, and your talks often incorporate a lot of background in prior art. In fact, 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 our listeners know they don't need to keep on bringing it up and i have a great picture which i will retweet of what connor and I were sitting at down at the awards. And I had been telling Connor all week,

you're going to 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. But, but if you look at that talk, you know,

at the start of that talk, you do something that I don 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 algorithms should be structured in C++. And if you have all this history in this background, you realize, oh, maybe we should have designed this algorithms API a little bit differently. But one of the key elements of that talk was this use. You're sort of like a DJ remixing some folks' other tracks into yours, where you use these clips from other people's talks, you use these patterns and the history from other languages

to sort of inform your analysis of C++. And so I think that's like a very core to your brand that 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 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. Yeah. It's, uh, so I guess, yeah, I guess the, the takeaway there is no, no, your style and like tailor your titles to your style. Um, it's interesting cause

I think it was at the, we, we briefly mentioned the Belfast dinner of 2019 that we both have fond memories of. And David Sankel was one of the individuals at that dinner. And he was trying to come up with like a name for the type of talk. Because some people were referring to it as like a meta talk, that it's like, it's a talk mentioning other talks. But David was not satisfied with that. 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 uh, more recently, but yeah, I guess so it works if it, if it's, uh, if it

syncs with your brand. Um, okay. But anyways, we should, we should get back to naming, uh, instead of just talking about, I think that's like a good branding. 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 area. You definitely, you use the same comparative analysis techniques that are common to a lot of fields of history and anthropology, but you just use it in tech, which... Well, so while we're on this topic, this was actually one of the things I wanted to mention.

I tweeted about this, but it's 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 a programming language enthusiast and I consider myself like a programming language historian.

For those of you that identify with that statement, I just stumbled across a talk yesterday that was actually linked to me on Thursday night while I was attending the Denver C++ meetup. I got linked to talk by an individual by the name of Galad Braka. I think I'm pronouncing that correct.

And he recently gave a talk called Array of Hope, which is on this new programming, APL-inspired programming language called ShapeRank. 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. But it specifically looks at your favorite, COBOL gets mentioned at the beginning, FORTRAN. It really looks at like the 50s and the early 60s and focuses mostly on APL and why it's a beautiful language and misunderstood. But anyways, I'll link it in the show notes. And I just, 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. And that's, there's another talk. I'm not even going to 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, which is a talk about like Fortran, COBOL, Lisp, 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 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 completely obfuscates that it's a programming language history talk. It's like the beginning of a quote, like on the something of something dot dot dot. And just like browsing the Strange Loop YouTube playlist, if you had seen the title, you would have no idea what the talk was about. And it's not, no offense to the speaker, you would have no idea what the talk was about. And it's not, no offense to the speaker, because he's one of my favorite speakers. I believe his name is Mark, insert something. Maybe I'll fix that in post as well. He's one of my favorite speakers. I can't remember his name, but. Well, he doesn't give talks very often anymore. So he only has a

handful of them. And even the ones 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 clicked through the slides. But yeah, it's not the same thing. Anyways, yes, titles and names of your talks are important. But yes, let's get back to just naming in software, software development in general. So what are your thoughts? What are we talking about? The reason that I wanted to talk about it this week is 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 C++ Standard Library. And this week we hopefully closed what has been a long and arduous saga in C++ naming. So there's in C++, we have a series of... Std function. Yeah, std function.

We have a series of function wrappers that are either in the standard library or being put into the standard library. So std function is the one that exists today, which is it's the type erased holder for something that you can call. So it can hold a function pointer, it can hold a function object, et cetera. And the idea is that you can say, hey, 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. And so that you can make an interface where you can pass in either a function pointer or a function object, et cetera, without having that interface be templated. And there's two new function wrappers of that family. There's one new function wrappers of that family.

There's one called function ref. Std function is an owning wrapper. So it owns the thing that you've given to it. Obviously, for a function pointer, you can't really own a function pointer. Functions aren't top-level entities in the C++ programming language, so you can't pass a function around as a variable. Functions aren't objects in the language. But a std function lets you take a function pointer and give you back something that is actually an object.

But it's owning, it owns the underlying thing. So if you pass a function object of your own into a std function, then it will own a copy of that function that you passed in, function object that you passed in. So function ref is a non-owning form of std function when you have some existing function object or callable that you want to pass into some interface, but you don't want to make a copy of it or you don't want the wrapper to own it. And then there's this other one, which it's basically an improved form of std function. 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. In particular,

it doesn't work very well. Well, it doesn't work at all when you have a callable thing that is move only or that is single shot. And so there's some other problems too, but that was the main problem we wanted to solve where you've've got some callable that you can just call once, and that is move-only, it can't be copied. Std function requires copyability, so we wanted to introduce a new form of std function that was for move-only, that would support move-only things and had some other fixes. And we originally were going to call it unique function a la unique pointer but that name died in a fire because people felt that it was not technically correct because while you can uniquely own a function object just as you know a unique pointer is a uni it has is a uniquely owned handle to some dynamically allocated thing.

And because unique pointers move only, it only allows one entity at a time to have ownership of it, which makes it very simple to clean up when you're done with it. But you can have that for a function object. You could have a unique function that just takes function objects and uniquely owns them. But people argued that for a function pointer, that doesn't make sense. Because, again, functions aren't objects in C++. And anybody could have that function pointer. You can't really uniquely own a function pointer. So on those grounds, the name unique function got axed because

it seemed to suggest semantics that it didn't actually have. In particular, it suggested semantics similar to unique pointer that it didn't actually have. So then we moved on to a very curious name, which was any underbar invocable. So function was no longer a part of the name at all. And the reason that it was called any invocable is in C++, we've just 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++? Well, so the ones, well, go watch my talk, plug, plug. That was an introduction to those language

facilities. But I mentioned this in the talk, and a couple people have told me that this is wrong, but this is my mental model for concepts. So, like, the comparison of sort of types to values, like a type defines the values that your value can take. So an integer can represent, you know, integer numbers, 0, 1, 2, 3. Float can represent, you know, numbers with fractional parts. And, you know, the double versus the float, you know, it's 32 versus 64-bit defines the range. Float can represent numbers with fractional parts. And the double versus the float, it's 32 versus 64-bit defines the range. So your type defines the values that 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 set of sort of types that are defined by a concept. And so the main, or at least in my mind, the main thing that you can use this for in C++ is to constrain your generic functions. So if you've got a generic function that takes a template, you know, type T, 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, in C++20. My favorite is to just, 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 with an auto. And then before the auto put the concept. That's basically saying this generic function can only take types that conform to this concept. And this is called, you know, adjacent things in other languages are called different names. So in Rust, they're called traits. In Swift, they're called protocols. In Haskell, they're called type classes. And they vary from language to language. but this is the general idea. What are they called in APL?

APL is a language that supports rank polymorphism and the things that APL supports. But yeah, APL on its own is dynamically typed. So I don't think without static types, I don't think you can have sort of a generics facility, concept-like facility. So in C++, the name for the concept for things that can be called, like as if by function call, is invocable. So the invocable concept, any type that can be called or can be invoked with the, you know, stood invoke function, which is a function helper for invoking invocable things, satisfies the invocable concept. And so that's the invocable part of the any invocable name. The any part comes from the type erase nature of this thing. So as I mentioned before,

that's one of the key things about std function and also about function ref. When I make the type of a std function object, it would be like std function for like a function that returns an int and takes an int. That might be the type of a std function. That std function could store, you know, some function object type. It could store some function pointer. It could store a different function object type. It could store some function pointer, could store a different function object type.

And so unlike just like a templated interface that might take something of the invocable concept, a std function has to type erase the underlying thing. It just takes the signature as a parameter, not the type of the thing. And in C++, we have a facility called std any, which is just like a generic type erasure mechanism. And so the idea was, well, okay, this is a type erased function, type erased wrapper for things that are invocable. So we'll call it any underbar invocable. And there were some that felt that this should be a general pattern, that we're going to have places in the standard library where we want to have a type erased wrapper for a particular concept.

The other one that's sort of in the works is any executor type eraser for the executor concept. You might imagine in 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. Maybe there's some place where you'd want to have any iterator. So that was the basic idea of this naming pattern. And it's probably worth mentioning how the library evolution group used to select names for things. The bike shedding process, although we try to not use that term. So the way we used to operate was anytime objections to a name would come up, there would sort of be some hand-waving saying, 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 upon a name was we'd pull up a blank text editor and the chair would say to the room, all right, suggest some names. There are no bad

ideas. Just suggest some names. And that is, we did this particular byte shedding on like a Friday afternoon after the end of a week of meetings. And so some of us might have been a little bit tired and giddy, but I recall, I think Mofunk was on the list of potential names for this. I think there were a few others like that. And then what we do is we 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. More recently, we've decided to establish some new naming policies. And the new policies are essentially, if we're going to 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 researched the name and that has some justification for

why it's a good name and why other names might not be good names. And this new process, a lot the naming of this facility. And so we settled on any invocable about a year ago. And I think some of us realized at the time that that name was not super great. And one of the problems with that name was consistency. Otherwise known as symmetry for me, personally. Yes, otherwise known as symmetry. So if we're going to 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. But at the end of the day, that was going to be a little bit inconsistent. And it was also not clear if people would understand, like just regular lay programmers would understand what any invocable is. If you don't know what concepts are, if you're not particularly interested in learning, that name could be quite confusing. It makes a lot of sense if you know about concepts and if you know the background, sure. And one thing to understand about C++ standardization, there are two different types of legal systems. There is what's called the French system, where the law of the land is all specifically codified in a fairly large, you know, body of laws. And that is what is enforced. And then there's the British system where you have a much smaller set of laws and guidelines for how those laws

should be interpreted, but you have a very large body of precedent, of case law as it's called. So the law often depends on what courts decided the law to be in the past. And so you often have to look at, you know, the precedents, the prior art, etc. The C++ programming language has a British legal system. 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 guidelines? Well, 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 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, 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

going to be inconsistent with yourself, you should know about that and you should be inconsistent willfully, right? If you're going to break from existing convention, you should do that and you should do that very clearly and you should try to set a new precedent. So what's the end of the story? What happened in the last week? Okay, so we went back to revisit the name of this facility in the past month or so.

And we settled upon that we wanted function to be in the name of it, not invocable. And 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 and deep question. So what people meant like that, you know, some people said, well, you know, the name any invocable, it suggests that it can hold any possible invocable thing. And it's not necessarily the case. There was a series of names suggested that were something like move only function, move only or movable function, etc.

And people questioned, well, is that really the right thing? Is that the key property that we want to document about this? whether the name needed to reflect the properties... Again, I think it all comes back to whether the name needed to reflect the properties of the stored invocable or of the wrapper itself. Like, 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 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 the name of this thing reflect how it's going

to be used, 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 think a lot of the discussion around this particular issue is pertinent to any discussion about naming. When you're picking a name, are you naming the thing? Like, what attributes of the thing do

you want to reflect in the name? Do you want the name to reflect the intended use cases of the thing, or do you want it to reflect what it does? And, you know, 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 spend a lot of my time at work in lengthy debates with people about names. 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 not an implementation detail, but it's just like a minor detail that,

that we can figure out later or 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 is such a hard time about names 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. And not only that, but you also have to ensure that names are consistent with similar and related facilities. And then there's a whole other facet to naming, which is avoiding connotations. So for any name or brand, you have some denotative meaning, 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?

I come from the concurrency world. One of the big problems in that world is when people use the terms tasks or threats. You know, there was some suggestion that we should name C++20's J thread, which was an improved form of the C++11's std thread. Somebody suggested maybe we should call it task thread, because that's what it's for. It's 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 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 gonna have secondary meanings to to anybody and if so then you probably just avoid it even

if it's a great name it's better to have an unambiguous name so yeah one there's a couple things i want to i want to uh mention so one of them is an apl anecdote um that you might be thinking oh how does apl tie into this well um ken iverson the creator of the language, cared extremely deeply about 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 getting the Oxford dictionary from Ken Iverson was like a very, it was a very meaningful gift. Because he would spend time like reading the dictionary, trying to find words that were evocative, that evoked like the essence of what you were doing. So an example is that in APL, the comma, 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 preferred word over catenate. But so that's the dyadic meaning of comma. But the monadic meaning, the one that just takes a single argument is ravel. So that's R-A-V-E-L. And what that does is basically, given your n-dimensional array, it flattens that into basically just like a one-rank array, which is just like a stood vector, a stood list, so a flat list of numbers. And the reason he chose Ravel was because the comma looks a little bit like a needle for like, you know, 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, you basically like are taking what was cylindrical and then putting it into a line. And it's so 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. And I read so I read a blog or an article 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 going to say but I can't remember at this point oh 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 I'm not sure if it's been mentioned on this podcast before but yeah in in lisps uh like closure 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 a driving principle in naming things is symmetry. So like when it comes to

std function, std function ref, and then what are we going to name the next thing? 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 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.