Live CEOing Ep 822: Language Design in Wolfram Language [Entity, Trim, and More]

Okay. Hello, everyone. Welcome to another Wolfram Language Design review, part of our Incremental Language Development series. And we have a few topics. Let's find out what they are.

So this is a continuation of a discussion we've had a few times, which is that we have a system for saying geoposition of an entity, and we get a representative geoposition. We want to do basically the same thing for date objects.

I agree.

And so Alan and Ben have been working on, kind of curating and going through different domains and seeing roughly what properties would correspond to a date. There are simple cases, and there are less simple cases. I guess I'll let Alan take it from there.

Right. I mean, and this. This isn't necessarily every domain that has a date property in it, but there were a few major categories that I thought would be a good place to start, and they were more sensible things that we could easily get hooked up to begin with. I think the simple cases are there's an entity type where there's generally a clear and unambiguous notion of this thing begins here, it ends here, and this is the date range that represents that thing. The ones further down, we get into cases where there are things that have maybe an inception date, but then don't really ever end, so to speak. Things like structures where the start or end can be measured a couple of different ways, and we have several different properties that could be used to represent one end of that interval. And so there's sort of a question about if we have these default properties, do we want them to be documented as. And to always map only to one specific property, or do we want to have kind of a hierarchy of things where if we don't have property X, then for the start date or the default date, we would use property B, property C, whatever, down the line, and then just some other categories of things that are a little bit weird. And I didn't want to get into the weeds with every possible thing, but the.

Okay, so the basics are the place to start. If we say date object of. I mean, just to be. Just to cut to the chase, if we say date object of Strontium, Right. Do we want to get the discovery date, for example? Am I making sense? That's.

That's one question. And that was why, you know, I wasn't sure, because most of the other cases are things where the. The date properties represent something more about the existence of the thing. Right.

We don't want date object of Tyrannosaurus rex to give us the date that it was discovered.

We want Era discovered by whom?

Yeah, or a planet or something like that.

Yeah, right. Okay.

Discovery dates. Thorny.

You know, one point is if we say timeline plot and we have a bunch of entities, you know, for timeline plot, what we really want is some kind of notion where timeline plot will ask for, you know, default date or something or, or date property or something like that, and it will either return a date interval or an actual date. Does that make any sense? There's different things. I mean, like date object.

If you did timeline plot of a bunch of people, it makes sense to get the date intervals they were alive or their birth dates, you know, Cleopatra, Galileo, et cetera. If you do a bunch of buildings, it's a little funky. I mean, the, the tricky thing is, you know, with locations, we have a pretty definite notion of this has a position or this is something that doesn't have a known position. There are weird things like art, where there might be a position associated with where it is now.

Yeah, sure, but. And there might be with. Okay, so the issue is, let's take a building. Okay, so some things. What do we think we're going to call.

So here's. This is a bit of a tangent, but can date interval represent disjoint date ranges as I'm thinking?

Okay.

Because I'm thinking of something like the Hundred Years War, which is generally considered, even though we call it the Hundred Year War. It's sort of like three separate conflicts with.

You know. Okay, so what we need is something where date object better be a single date.

Right.

Do we agree?

Yeah, we definitely don't want date object of something spitting back an interval.

Right.

And date interval should always be an interval. If it's a single moment, it can be an interval that is one.

Yes. So that's fine.

So then data object of person. What, what then what would data object of, you know, Albert Einstein do?

Well, I think what it should do, my feeling is probably what it should do is produce a message and then produce birth date. That's what I think, because I think we can't know, but it's better to not act dumb as a stone. And in the case where you just say, I mean, timeline plot would request date intervals or default dates. You know what I'm saying? What are we going to call that? What are we going to call the thing that timeline plot requests?

So I think the analogy I was thinking is under the hood for things like geographics. When you give it an entity, it looks for three or four properties at the same time. And, and depending on what of Those properties exist. It will return something. If you ask for something that has an extended region, it will use that, but if it doesn't, it falls back to geoposition.

Okay, but I think here it's going to be a little trickier because I think that we're going to want it. We're going to want something where we curate what. What it gives. You see what I'm saying?

Yeah. We could just call it date. We could just have a property that is date and that is the default dates effectively. Or representative dates. It's probably a little more wordy than we want.

Date value, Date. I mean, because I feel like. You think just date makes sense.

I mean, I guess.

Why not? Why not? Yeah, yeah. Why not? Okay, so that's my suggestion. We've got. Are these three accessors, Are these the ones we care about? Data interval and time.

Time. Time object is not super meaningful in most of them. I mean, it could basically just take the time part out of a data object if we really want to.

Yes, yes. Okay. Is there any other function that is going to be relevant for this? Like is there a geoposition thing that. That should actually have a date in it?

The. The fourth argument of geoposition can be a time.

I know, I know.

Yeah.

So historical countries might have something like that.

Yeah, that's true.

I mean, are there any other functions that access this other than the ones I've listed up there?

I mean, any of the date functions could conceivably be set up where when given an entity in a date argument, it could effectively.

Well, so duration would be an example.

Yeah.

Okay. So duration of an entity would access the date entity of that date property of that entity. If the result is a date interval, then it's cooking along.

Yeah.

Okay. What other functions? So. So generally we need to figure out what functions are going to access this date property. You know what, what functions can take an entity and then we'll do this. Make sense?

Yeah. I mean, it's maybe a stretch, but nearest works on dates. It could conceivably. I mean, I don't know that I want to overload nearest on entities to default to dates.

Yeah, I wouldn't do that. But let's just look at what. I'm looking at.

There's some objects where. Like random data.

Well, date bounds, for example.

Date bounds would be another. Where we're looking at the end points.

You know, and I can imagine putting something in. Well, let me just think. I mean, if you put in astral position and then you say Battle of Hastings or something See what I'm saying? If I say sun position, You guys may never have heard of this thing. British school children have heard of this.

So one.

Yes, we. We know what the battle beast 1066.

Yeah, good. I have no idea. You know. The history about the so called American War of Independence which is what the American Revolution is called in British history education is spotty I think. Anyway.

Yeah. Sun position.

What we need to know about it. We want you guys, end of story.

Some of the astro functions would be a little tricky just because things like sun position or moon position can take either locations or dates alone.

What the heck did that do?

I'm guessing it's looking at the current. The current sun position at the location associated with the Battle of Hastings.

Yeah. Well that's kind of iffy.

Yeah it's doing that because right now sun position interprets all entity inputs as being locations. So it says what's the location entity value Happily says here's the location and it just runs with it. So if.

Right.

If we allow entities to represent dates then it would need to have a decision tree and say. Okay.

Okay. So that's I think a more luxurious point.

Yeah. There are only a handful of functions that. That is likely to appear for where a single argument input could be a position or a date.

Right. Okay well okay, so we've got some, some versions of this. So now let's take a look at. Okay so now the question is what do we do with each of these things? Okay. The sort of the default. Yeah. Sandra is commenting date object of an interval could just give the center. I. I don't think that's a great idea because I think that it really. You know, the center between birth date and death date. The, the center between birth date and the person is still alive. What's their death date type thing. You know what the heck do we do for. For the date interval. Okay so date interval of a person. How do we deal with that? Who's still alive? That is.

I guess we would probably have the end date be infinite future until such a point that we have. It's like with. With country our.

Or can we do it at indeterminate.

Yeah. I was going to say the future is a really long time. It's a really long lifespan.

Yeah. I think it's going to mess things up. I think it'd be better to have the arithmetic fail if you understand what I'm saying.

Yeah.

It would probably be good to have an indeterminate start or end point for data intervals and there's a Question about whether having a indeterminate date standalone is useful.

I think we're going to need an indeterminate date because you're going to be able to say, what's the end point of that interval?

Okay.

See what I'm saying?

Yeah.

The reasonable question is whether we want it to be the same indeterminate that we use elsewhere with its own, you know, arithmetic rules. Maybe that would work. I don't know.

I don't know if that would work. Or whether we want a separate thing called indeterminate date.

The reason I'd be against that ladder is because we might want it for other things, not just dates. But, you know, if indeterminate could be made to work nicely in this setting, that would be great.

Yeah. I mean, we added infinite past and infinite future specifically so that we didn't run into arithmetic with infinities in all cases. We have. In a lot of cases, I think.

We should add indeterminate date. Okay. Yeah, I think that'll be useful. And that way we can fill that in and instead of saying missing.

Missing indeterminate or missing not available, we can say.

Yeah, we could say indeterminate date. I mean, the things that are going to happen, we just don't know when.

Right. If you say death date of.

You know, everything ends.

Yeah.

It will happen eventually. We don't know when.

Right, okay. As opposed to something that. Yeah, okay. All right. Okay. So on these, single date is what we've been calling just date. No, no. Just date would be the date interval, which could have an indeterminate date at the end. Correct. For a person. Does that make sense? Hello?

Yeah, I'm trying to think about it. Yeah. I mean, we could certainly have the default property for date go to date intervals because that's the most informative.

That's what we want to do. I mean, that's. We can just check these off. Okay. Person goes to date interval by default.

Yeah.

Right. Birth to death. But if there's no death, it's indeterminate date. Makes sense.

Okay.

Yep. Military conflict. If it's still going on, it's indeterminate date for the end time. Right. The otherwise it's state interval music act. I don't know. What is that? That. That. That's presumably start date to end date. What's that?

Right. Which also. Which also could still be in existence. Could still be.

But it's indeterminate because it's not. It's not missing or infinite future. It's just indeterminate.

Right.

Historical country. Got to start and an End.

Yeah, yeah.

Interval. Tropical storms start an end, unless it's still ongoing. Country, I think they.

They become historical countries when they cease to exist.

Right. So I think we assume their infinite future. We have the single date, by the way. Okay. When it has to be a single date for a person, I think it's. It's the birth date, but with an error message. Makes sense.

Yeah. Like an ambiguity message.

Yeah. I think all of these. Now, tropical storm, the start and end may be close enough together that we really just want to give the start date. If you just ask for the date or the center.

Yeah, Just, of course, the early date of it was this day, actually.

That's right. We could. We could just ramp up the granularity for tropical storm and historical country and music act and so on. And these things which are in the past, we could just ramp up the granularity and have them be a single data object, possibly with a message to say, we're doing that. But that would be the most useful thing. I mean, you know, if what we want to know is roughly when did the second Punic War happen? You know, it will be nice to know the specific dates, but if we asked for a single date and we just want to plot it on some graph somewhere, you know, roughly what was the, you know, where had the press procession of the equinoxes reached during the Second Punic War? We don't really care what the specific date was, when it started and ended.

But then for some situations, we want this to be graphically represented in date plots.

Absolutely. But I'm saying if you just say date, object of the thing. Right. If you're forcing a single date, what date do you get?

Now? I understand. I'm just saying that granularities typically don't end up visually.

I see what you're saying.

Well.

I think it's okay. I mean, you know, because for something like timeline plot, it is going to do that because it's going to produce the date interval. All right, let's keep going for other things here. Okay. Yep.

Right.

Now for things with. I mean, I don't know how we have these things encoded, but, you know, things with. I'm sorry, did we decide on the beginning or the middle or did we not for, for the cases where we asked for an instant.

I think it varies. I mean, like, for a person who's still alive, it would be pretty silly to give the middle because we don't know what it is.

Right, Right.

So I think in that case we have no choice but to give birth Date, the person doesn't exist unless they were born. So we know there's a birth date, a country. For a current country, I think it's pretty silly to ask the date of a country. But if you do, I think we probably have to give the independent state and that's it.

Yeah.

Right.

What about the.

Well, actually, I'm gonna.

How these are encoded. But what about countries that existed and then stopped existing?

And then historical country.

But what if they started existing again? So like Poland, right, It existed and then during World War II, it stopped existing.

I would say give the most recent independence or founding date.

I think in historical country, we've got those essentially represented as separate entities, don't we?

I think so, yes.

Okay.

But I would argue that country. I'm. I'm changing my mind. Because if you plot countries and historical countries together, I think we should have country be infinite future for the. With it be a date interval from the independence to the infinite future.

Definitely. Right.

So that it goes along with historical country. Okay. So then there are these. Okay. Structures. Oh, boy. I mean, the point is most structures will not have end dates, Right? No. Structures in art that we have, it's the most.

Yeah, yeah. If you're qualifying it that way. Most of the structures we have, we're weighted more towards ones that exist present times and recent dates. So we, we are heavy on things that still exist.

Right.

But that doesn't mean we don't still have lots of things that don't exist.

Okay. I suggest that the single date is basically the opening date and that if you ask for a date interval, It's opening date to infinite future. Basically, in the event that we don't.

Have an opening date or an opening date. Doesn't make sense. Do we fall back to a secondary thing like construction end date, construction start date? If we have this.

Yes, yes, yes.

Okay. That was, that was really one of my questions. Do we want to. Do we want to only have these things mapped to single properties?

Oh, no, no. We should do the best we can. Like a castle. I don't know whether, you know, maybe the lord of the castle had an opening date with, you know, big ribbon cutting. Yes, yes. Right. Certainly. If it's a Disney heading, maybe. Yes.

Right. And that, that's really one of the kind of cases that I had in mind. There are things that we know they, they started construction, but they may have started to be used more or less before construction ended. And we might not really know when construction ended. It gets fuzzy.

Just get some date. I mean, you know, is it 1200 or is it, you know, 1970? You know.

Yeah.

The great.

No, if. If that's. That helps a lot just to have that be. Okay.

Okay. If you insist on a date interval for something like a board game, I think you just get Infinite Future for this, for the second date. Do you agree?

Yeah, it makes sense. I mean, it's not indeterminate like these. These are. They're all essentially creative works that.

Yeah.

Will live forever as long as they exist in.

It may not be in production, but it still exists.

Right. Yeah. They are ideas on some level. So. Yeah.

Okay.

And then I, you know, mix of things. Kind of the. The question we were talking about before, do we. Are there cases where we would want to have discovery dates for some of these things or like meteor showers? Do you want a discovery date or are you expecting the next instance or does it not even make sense to try to handle some of these things the way we're handling the rest of these state properties?

Thinking. Yeah, I mean, something like a chemical element. I mean, the only date I can imagine associated with it is a discovery date.

Yeah. I'm just wondering if it's. If it's more useful to give it a discovery date or if it's more useful to say a date isn't a meaningful property here. At least date object of tungsten.

I think we should do a courtesy. I mean, in other words, if somebody has a list of exoplanets and they do a timeline plot, why not make it work?

Okay. I mean, maybe this is something stupid that nobody would want to do, but what if I wanted to make a timeline plot that included planets, dinosaurs and elements?

Yeah. That's a can of worms. Well, I mean, if. If they are. If we have discovery dinosaurs, we obviously want when they lived. Okay. The question is, should a discovery date ever be there? I mean, this is a. Kind of a philosophical question because let's imagine, you know, these are things created by human effort at a certain time.

Right.

Tropical storms are not. Presumably. I don't know, maybe we should just not have the discovery dates, not default to discovery dates. If you want discovery dates, ask for them.

I like that. I mean, we. It's not like we're preventing people from choosing specific dates when we have multiple dates for a given entity.

Yeah.

I'd like the automatic behavior to be as intuitive as possible.

Yeah. So let's not do discovery dates.

Okay.

Okay. Let's do existent states, basically. So I'm not even sure that Metro shot.

That's an easy thing to explain. And Document to.

So, yeah, I mean, a deep space probe was probably being assembled in, you know, some place for a few years before it was launched. But I don't think that's relevant.

Right, yeah.

When we were discussing buildings earlier, I didn't bring up Sagrada Familia, which, you know, has famously been under construction for close to a century and a half now.

The.

What's that, Stephen?

Yeah, I'm thinking about famous math problem and whether we, whether this proof date makes any sense at all. I was not thinking about things that have been continuously under construction. Think software. I think the proof date thing is weird. We all fall off. I mean, oh, gosh, you know, Fermat's last theorem. Is it relevant when it was proved or when it was formulated? If it has been formulated but not proved, maybe the canonical date is simply its formulation date. If it has been formulated and proved, maybe its canonical date is its proof date. Because, you know, you state a theorem and you say that was a theorem from 1822, the fact that somebody had suggested it in 1715 is washed away once it's proved. Am I making sense?

Yeah.

So I say the canonical date, I think should be if it's formulated but not proved. It's the formulation date. If it's proved, then the proof date. And if you really insist on date interval, it's hard to see how that works because the formulation date, you know, the theorem might not be true. Well, it says famous math problem, so maybe that is not so important. I mean, I'm wondering, does it go to indeterminate or to infinite future? Probably goes to indeterminate because presumably if it's a well stated problem. Yeah, it could be very indeterminate. It could be proved that it's unprovable. Well, that's my suggestion anyway, for this. Okay. For dog breeds. Again, that's not relevant, I think.

Right.

I think if, if we, if we want to. You want to get through some other topics? I think the rest of the things in here I think we can probably process in accordance with some of the guidelines we came up with the sets above and just share that list and make sure that nothing is seems glaringly off to people, just so we don't get too deep in the weeds.

Okay, what's this next one?

So this next one is a commonly requested feature in the quantity and unit space, which is that it is somewhat difficult to explore the existing space of units in Wolfram language. And since we have physical constants as an entity domain, I am posing the question, does it make sense to have physical unit as another entity domain.

What the heck is a lecter Kelvin?

It's one of the in historical times proposed prefixes that were never officially approved.

Okay. Along with McCree Kelvin.

Do you know what the prefix meant?

Value.

I mean there have been a couple of times extended first to 24, then to 30 ish. And in this intermediate times, people already started using various versions.

Oh, there it is. A hundred thousand. Oh, it's like lack in. Is that right? Isn't is like lack in an Indian number system? Is that. Is that 10,000 or is that. This is what I want.

You want hindi?

That's not useful.

Try transliterating that. But I'm not sure. Yeah, there's lack.

Why does this come out in a different window? Not this stupid problem again. Can somebody please report that? Yeah, taking a screenshot. Okay, so there is some lackey thing, lack related thing here. Cool. All right. What is a hertz Kelvin relationship? What do you think that means?

I am not sure. Sure Eric would know. But he's not here right now. He's out of the office.

And why did that.

So it's doing that right now because this is faked. This is using a local entity store. So.

All right, so what is the question? The question is.

Do we think units or physical units make sense as an entity domain? We've already collected and curated a lot of data about them, but it's not exposed through the entity framework. There's some nice things about the entity framework, such as being able to use implicit entity classes to.

What would this be for other than people randomly wanting to scrape stuff? I mean, what would it be for?

And I think that, you know, one of the common complaints is that we don't have a list of supported units anywhere. Part of that is because it's dynamic and part of that's because having a big long list of 5,000 units isn't very.

Including xenokelvins and lacta kelvins is not useful.

I mean, we have, we have a criteria basically for whether we think a unit is useful or meaningful enough to be included in the language. You know that that bar is not super high for units that are part of common unit domains or unit dimensions. You know, if it is a temperature unit and it is not marked as being esoteric, then we generally include it.

Okay, but the issue is this. I mean, this way of getting at temperature units is a bit messy. I mean, what does temperature unit mean here?

So that is the unit dimension associated with the unit.

Well, what if I want force? What if I want the same thing for force.

How do I get that with this implementation.

Either? I don't. Is that right?

No, no, you would have. You would have on the right hand side, arithmetic, multiplicative expression in the base units. Dimensions.

Yeah, in the dimensions, yes, agreed.

So what is the functionality that we're really looking for here? Is it. Show me all temperature units?

I mean, I think that is. That is one part of it. That is a.

What is that? What is another part of it?

Another part of it is being able to, you know, look up individual properties that we have for the units that don't naturally fit somewhere else in the language. We have ways to say, you know, what is the singular form, what is the plural form of this unit? But they're cumbersome and they go through the typesetting forms or what are the unit systems.

So these are properties of units?

Basically, yeah.

So why isn't the entity type just unit?

It could be unit. I was calling it physical unit for symmetry with physical constant, but we could just call it unit.

I would think it's just unit. I mean, and then I think it's fine.

But.

But to have notion.

Sorry, but does it include non physical units like currencies? Or is this really.

It does currently.

But also here's a more serious problem in, you know, if I type meter, what am I getting? Am I getting one meter?

You were getting back one meter. Yeah, because right now there is no. Our only representation of units in the language is either as a string or an arithmetic combination of strings.

Right. So this will be an alternative. If I type meter in natural language.

Yep.

It could give you entity unit of meter.

Right, but that will be an alternative interpretation. Probably.

Yeah. I mean we would basically at that point we would want quantity and other things that consume units to know that entity of type unit can be converted to its canonical form. But if you said quantity of three.

We have this thing, at least in some contexts, of quantity of none comma unit supported. And when exactly you get that, if ever from entity value.

But yeah, that. That is a. A way to support the notion of orphan or of units without a magnitude as the return from alpha.

I think it's better to have an entity type unit.

Yeah, I think that's basically a hack. We have to let it work that things like that control equals.

So by the way, these are not correctly spelled right, because they.

They.

Those should be the print names.

Yeah, this is just a quick entity store I threw together based on data that's already in Wolfram language. So if we like the idea of this. There are basically two complications that I think we should sort out, which is how we deal with compound units like meters per second. Is that a single entity that then has a Wolfram language form that is the arithmetic representation of the string.

Ouch. No, because that. That's like molecules, you know, it's, you know, length, time to the minus 17 or something.

Right. Or a mathematical function, you know, we don't have entities that are arbitrary combinations of functions. Yeah, that was kind of my preference, too.

I think if it's named, we have it here. Like a Newton is a named unit of four. Or, you know, for acceleration, the acceleration due to gravity is probably named, but an acceleration. Wait a minute. How does this relate to physical quantities? So this probably should have a physical quantity.

Yeah. The relationship there might kind of be reversed. Where physical quantities have representative units, units can have possible physical quantities. But meters is not only a unit of length, it's also a depth with.

But that means. Okay, look, here's a problem. Let's say that you say speed. What are the units of speed?

Okay, but we do already have a physical quantity entity domain.

I know.

Yeah.

Okay.

Right. But here's the question. Units of speed.

Yeah.

Okay. You could have anything by anything, you know, it could be, you know, light years per millisecond. Right. That would be very unlikely, but you could have that. So that's a combinatorial explosion of possibilities.

Right.

And I don't think we have. I don't think we want to set this up where we say, give me all possible temperature units or all.

No, I think it's named temperature units.

Exactly. Yeah. I think treating this as an entity domain, where these are the entities that exist, they're all named and they're. You know, we can have a property that is a quantity of one of them or the Wolfram language unit representation of them, and then you can combine those as you see fit. But here are all the named temperature units. Here are all the named currencies. Here are all the.

Right. And so you can get that presumably with an implicit entity class.

Yep. And we might have entity classes for, you know, the top five unit dimensions.

The only thing that's tricky there is, as Michael says, a meter could be a physical quantity corresponding to length or this or that or the other. And the way things are set up, there's no obvious way. 2.

Why is there a problem? I don't see one.

Okay, well, explain how you would get everything that is a unit of length. I mean, it seems a bit messy to get it? Because you have to say something about contains, don't you? I guess that's okay.

I mean, no, we would have, in physical quantity, we would have the length physical quantity, have a property that returns the corresponding units.

That's fine. That's just fine. Yep, that will work fine. Okay, and then the default for meter would be probably still 1 meter, but.

You could say as a unit. Yeah, and then we already have something we already have internally in the language, a framework that says, you know, this is a quantity function that is expecting a unit only or a quantity in units. And we'd basically just add support for entity unit there.

All right, I think we've got a plan.

Okay.

So this is kind of related to the date discussion above, or at least has some overlap. We have this functionality in Mindate and max date where you can give a granular date object and then you can give a granularity that you would like of the minimum or maximum date.

So.

So I want the last second or the first second of today, the last day of this week. It's also nice to get the midpoint or potentially some point along that continuity. You know, we do this internally for calendar conversion because if you say convert this month to the Julian calendar, the start point is offset, where you'll end up getting June instead of July.

Well, I mean, if you're making a plot, for example, it might be useful to have a mid date where you're continuously varying your Q quantity.

Yeah.

And so I think we have this notion of a midpoint instant inside a data object which gives you the instant corresponding to the midpoint. But we don't have an easy way to get a granular version. So like that first mid date example I have is give me the midpoint day of this year it was a few weeks ago, or give me the midpoint week. And then the main question I have, I think this is useful, but it might be nice to generalize to handle either a quantile or a blend specification where you say, you know, I want. By default it's probably the 50th percentile, but I might want the day that is a third of the way through this year or the hour that is 2/3 of the way through this week.

Yeah, I think that this idea of having a blend like specification of mid date where you give two dates there sounds reasonable to me.

Then I guess the last two questions are, do we like the name mid date, or does something like intermediate date sound better?

Midpoint date, midday is kind of fun.

And then the second question would Be do we want to extend the functionality we have in mind and max date to have a proper first, first date and last date? Because min date and max date behave differently when we're hand fed in a list of arguments, we can't thread over them. It will pick the minimum date and give you the date corresponding with the corresponding granularity. So min date of yesterday and tomorrow. If you evaluated that, you'd get the first hour of Tuesday.

So what are you proposing?

So what I was proposing is that it might be nice to have a listable version of this with first date and last date. It isn't a deal breaker. You know, you can always.

What do you mean? But how can we do that? We already have. We're not going to have another function. I mean, min date already does what it does, right?

Yeah. And if. If you do mid date and basically say zero, then you would effectively get this functionality also. Yeah, but I was just wondering if it's common enough of a case.

No, we. We can't have another function for this. I mean, both min, max and mid all return just a single date, which is the right thing.

Yep.

Okay.

I'm going to look at this very quickly, but I would be really.

So this is a little utility function that.

Why isn't it. Why isn't it reverse applied?

This is reverse applied with the exception that it only swaps the position of two arguments. And so my initial proposal is going to be. Would this be a useful variant argument structure to have in reverse applied? Or is it too confusing with the fact that it's called reverse applied? But then if you provide a third argument.

Let's cover this another time.

Okay.

I think these are for another time. Okay. Yeah, I think.

This last one is about having other schemas available for Create uuid.

That's a good idea. Yeah, it's a good idea, but I don't know exactly how. Yeah, it's a good idea. We should have that.

But we'll circle back to those last three another time.

All right, thanks a lot, guys. So, excellent. Until the next time.