Live CEOing Ep 718: Language Design in Wolfram Language [KeyValueScan, KeySelect, and More]

Okay. Hi, everyone. Welcome to another Wolfram Language Design review, part of our incremental Language Development series. And we have a variety of candidate functions to talk about today, which I. Are these coming from the function repository?

Some are coming from function repository. Some of these are older ILD suggestions. This is kind of the switch over from some of the old design notebooks that we've been going through for a while to wfr. And there's some of these that are kind of interrelated.

What fraction are we through the old design notebooks? Have we pretty much mined those out?

We have pretty much mined them out. The remaining stuff is basically specialty things that we forwarded on to specific groups. So a couple of suggestions for import, export, etc.

Key value scan.

So we have key value map. I know this was an old older suggestion, but there's potentially some merit to being able to.

Do we care? I mean, to me, having this is not high cognitive load, like people will understand what it does, you know, the.

Right. I mean, I'm not sure I see the value in this. Right. Unless it, you know. Right. It's key value map. Semicolon. Unless.

Well, you know, big.

Oh.

I, you know, I guess.

Right.

Right.

I guess it's right. Yeah. Then it doesn't construct the return expression. So it. Yeah.

And also it has the possibility of having a return in the middle of it.

For example, does scan respect. Yeah, that was the thing I couldn't remember.

Yeah.

Because I so fairly used to say.

I would say this is probably worth having. It's easy enough to implement. It has. It's not difficult to understand what it is. Seems sensible to me. It doesn't seem like it's a, you know, I can't immediately think of a fantastic use case, but I can think when we have more out of core kind of association like constructs, this is going to become more interesting.

Yeah. I was going to say the main use cases I've come across for something like this are, you know, cases where I'm working with a large collection of data that's in an association, which is something that happens in the Units framework, for example, and I want to batch process a bunch of things that has a side effect, you know, that's often setting something. So it's not a huge problem to use key value map right now or.

To basically, why not have this? I mean, scan is better than map if you can use it. Okay. Yeah. All right. Key. Select. Select. Third argument is a count. Right.

Select's third argument is a limit. Yeah.

So it's I think this is a no brainer. I think we should have it.

Yeah. So I think the, the only potential controversy here is that select is somewhat different than a lot of the.

I know, have level specs, but there are no level specs and associations anyway.

Right. So I think it's pretty uncontroversial for the, the association case. But that leads into the next discussion point which is having a select function that does have a level spec. You know, we can't really modify select at this point.

Right.

If we added a fourth argument then it'd be in the wrong position to every other function.

Yep. Why is.

Which by the way, is exactly what Tree select did.

What did tree select do?

We have a fourth argument. That's a level spec.

That is a level spec.

Why not just make it an optional third argument?

Because the third argument is account.

Yes, but it could be an. Right. I mean the three argument form is, you know, if there are three arguments, the third argument is account and if there are four arguments, the third argument is a level spec. Just like, you know, I see one argument log. The first argument is the thing to take the log of.

We haven't done this very often, but.

Right. It's. It's pretty rare, but it's not without precedent. I'm not sure we've ever done this in the case of level specs that. I think this would be new in the case of level specs.

Let's just understand what the utility of this is. Anyway, so this is saying. I'm actually totally confused. I mean, in other words, this is saying.

Well, I suppose if you want to select just a map.

I mean, I don't understand why this isn't just like.

It's like cases. Cases. You can provide a level spec to.

I know, to, to pick things out, but I think it makes more sense in the case of cases than it does here.

Why? I mean, I don't necessarily. I don't necessarily disagree, but I frequently.

Find myself using cases with a pattern that's just a pattern test when what I'm really doing is selecting.

I mean, I get the. I guess the more interesting question is, is what is the structure of the return?

Right.

I mean, is it cases?

It's going to be flat. Is select going to mimic the structure of the input?

Yeah, exactly. Cases makes more sense because it is just reaping, so to speak. You know, it's just making a final.

List of results when select could do this. I mean this select at level is apparently not doing that, but which I actually feel is A bit strange, actually. I think I would.

Right.

If you're going to have level specs that aren't an integer wrapped in a list, you almost have to make it flat. I can't even wrap my brain around how it would work if you're mapping it like at level two and four and then trying to maintain structure.

Yeah, what it's worth, Tree select gives a flat list.

Okay.

For this exact reason.

I hadn't even thought of the flat list case. I mean, as we discussed. I mean, and by the way, I don't have a horror of the argument order being. He says of the argument order being different if it's giving a flat list because it feels a little different. I mean, it's different from what happens in cases where you really are going.

I mean, cases gives you a flat list also.

I know. Okay, so it's a specious argument, But I mean. So the default is an infinity comma. Well, no, not the default. I mean that you could. In order to get.

It's level one by default.

Yeah, right. But in order to get all the elements on level whatever, it will be infinity comma, that level comma, the level specification. Okay, again, let's walk through this. So, Rick, in your examples, do you want the reaped flat list or do you want some kind of thing where it's in situ?

Usually just the flat list. Because for most expressions, what you would get probably wouldn't make sense if you just tried to preserve the structure.

Yeah, Actually I. Yeah, I kind of agree that this is useful. So now the question is, let's look at tree select for a second. I mean, what did. What happened in our discussion of tree select that caused us to have the arguments in the opposite order from select?

And I will point out that no.

We followed the argument order of select.

No, we didn't of select because it's N. But then select didn't have a level spec. Right, Right.

But then our choice for level spec is. Is inconsistent from every other function that takes a level spec that has it in the third argument.

I see. So level spec for select. I don't quite understand. If you want everything.

Right, if you want everything at a not default level, you'd either need to say infinity or automatic or something like that.

Infinity or all one of those.

Right, but it's got to be all comma two, that would be one possible syntax or two comma. All right, Now in the case of cases. Are you telling me that's how it works? It's I can say level comma n I see. I have to say the fact that I have to say one, you know, comma, one, comma, n has always been a bit frustrating to me. In cases. Yeah, I mean, in select, it has to be in that order.

So an optional third argument.

I think. So what do you guys think? I'm a little worried about this. What other functions are there in the family? Like count, things like that position. Right.

Well, I think those all follow cases. Right. Those are all pattern matching based functions. So if I look at. Right position. Right. So position follows cases. It's expert pattern level spec max number. Well, count count probably doesn't take a max number because it's counting. Right. So.

Yes, but might still. It might still.

Okay. Well, it's not documented too well, so. Yeah, I mean, I suppose the. I mean one possible out. I don't know that it's any less ugly is to have the level spec as some sort of option.

Yeah, I don't really believe in that.

Kind of like the optional third argument. Maybe it's because I'm used to tree having an optional first argument, which is also weird.

You know, it's even more bizarre than this because brace to brace, which presumably works in cases for the level spec, would clue you into the fact that it's not. Well, I don't know. Does select take. Is it a take spec, the thing that's in select?

No, it's. It's a count.

Right.

It gives you the first N elements. So it has to, it has to be a. It has to be a positive integer. I mean, I suppose, I suppose the, I mean one issue. Yeah, no, no, never mind. That was a stupid statement. But I, I'm. Yeah, I'm pretty sure that, you know, it has to be right. You can't do minus one say.

Right.

Yeah, it wants to be a non negative integer. Non negative, not a positive integer. So what does zero do? Oh, you can put in zero if you want to get the empty list.

The best way to get an empty list.

Yeah.

Well, I will say that that is the most efficient select possible. Yeah, it runs in constant time.

Right. Let's see.

I also tend to favor the optional third argument. I don't love inserting a new argument in a new position. But as Itay said, there are, there is precedent for it. It's not done super frequently, but it does make select symmetrical with the other functions.

Oh yeah.

Consistent with them.

Right.

And. Well, I mean, and then the question is, should we change tree select, which is experimental, to match select.

Well, Ian, what's.

Absolutely.

Yeah, okay.

We only had it fourth to avoid having to step into this problem.

So we change this case. Mm, fine. All right, let's do it. Right.

So these are two similar resource functions that deal with selecting either indices or positions or the. The result is either an index or it's a position spec.

How do we deal with this? In nearest, don't we have a mechanism for specifying the return structure?

Yeah, yes. Properties annotation. Right. The.

This thing take largest.

Likewise.

So why aren't we doing the same thing with select if we have an arrow property? Well, the problem is because select is much more structural.

Yeah. Select can take a rule as a first argument.

Yeah, it would be.

It would be kind of a silly use of select, but it is, I guess, a valid use of select.

Yeah. Okay, so this is something that finds positions at which a particular criterion is true.

Right. So we're not returning the values, we're returning either the index or the position where the criteria is true.

Yeah, it's the select analog to finish the well, analogy cases as to position as select as to what?

Yeah, And it doesn't relate to things like pick and so on, does it?

I would hope not. Pick being the miserable function that it is.

Tell us how you feel.

Yeah, yeah. No, and nobody quite agrees on. On what it actually means. I mean, in sort of trivial cases where, you know, list and. And VAL have exact. Are identically shaped, then we. We all agree. But the moment there's any room for interpretation, we don't all agree on what it means. And we're not.

And then the implementation is. Is then the guide and the implementation is misery.

I see it.

It not only does do people not agree, but what it's implemented to do disagrees with everyone.

Oh, gosh. All right, Well, okay, so this question here. Didn't we just add index cases to various other functions?

I don't believe we added the index and value.

And how is this related to.

Supplied?

Supplied? Yeah, yeah, that.

I mean, my initial thought with this was that it was somewhat closely related to position largest, position smallest, which we did a couple of versions back. You know, this is a slightly more general function in terms of taking an arbitrary criteria.

Would it make sense to have the rule syntax like nearest, but it wrap it around the. The function being passed to select rather than the first argument, because you could conceivably be trying to select either the left right inside a rule, but a rule would never be a thing you want in the right in the selector.

Right. So you'd need to remember your parentheses. But yeah, And I, and I think.

You could potentially use supplied to give different arguments to the test. But I don't think it, I don't think supplied should affect the output or.

No, the. In the, in this rule syntax that we're talking about, the string goes on the right hand side, not the left hand side. Right?

Yes, but the point that you're making.

Well, I'm just saying that means we don't have to worry about parentheses because the ampersand will be on the left side of the rule.

Fair point. But there's also select, indexed and so on, which is what supplied should deal with.

Correct?

Yeah.

Right.

Yeah. Indexed in the sense of. It takes the index into the test.

Yep. What other missing functions are we going to immediately think about if we add this?

Trying to remember what. What we've already added it to? I remember we've added it to a few things recently, but I. I honestly don't remember. What does anybody else remember?

Some stuff with. Fine. Shortest tour, I think.

Oh, yes, yes, yes.

Well, we have the triple position cases count if select is to position and this. Sorry, if select is two cases and this is to position that it would be the equivalent to count.

I don't follow that.

So the triple count position selected always go together again, count, position, cases. Now, select is the equivalent of cases and I think this function we are discussing here is the equivalent of position.

Yes.

So the question is, do we need.

The equivalent of count, select, count? Yeah. How many things satisfy this criteria?

Will.

Does count by have any hope of achieving that or is that too convoluted?

What does count by? Do we have count by?

Do we have account by? Yeah, there's always the possibility that I'm completely making this up.

Counts by counts by counts.

Count by is a different thing.

Okay.

I agree that there's also a count here that.

I just put another one from the function repository in the chat where I find this useful sometimes. You know, I used to find myself writing get the positions and then take the positions from expressions all the time and this just kind of combines it into one.

Yes, this is useful. I mean, there's also just turning expression into its.

Right sparsify or whatever you want to call it.

Right into its parts. This is almost like part association.

Yes, but with a test. With a pattern test.

Yes. Although it could have a select too.

It could.

There could be position select, especially now that select has level spec.

Well, I prefer. I mean, part association. Seems better for that. I don't know. Let's try and get a more systematic report on all of these kind of orthogonal cases. Okay. Okay.

Take a proper inventory of the select related functions.

Yeah. Select cases count across and their return values and what they eat and associations and things like that.

Right.

So. Okay, so I'm not sure exactly what this function does. Right. But basic, the basic issue I think we're dealing with is that, you know, by the central dogma, you know, cases cannot see the keys.

Yep.

And so if you want to do some sort of cases that can, you know, contest the keys and possibly.

I don't understand why supply doesn't solve this. I.

No, I think this is the rule thing. What did we call it? Like position pattern that simultaneously matches the expression and its position, which in this case would include the key.

Right. Okay. Yeah, that, that's. Yes. If we had somebody to implement position pattern, that would be, that, that would be a solution.

Well, position pattern sounds like a special case of supplied.

Well, no, go ahead.

Right. Supplied lives in the function functioning world in the map world, whereas position pattern lives in the, in the cases and pattern matching world.

Yeah, position pattern sounds like a really good thing to have. However, key cases is a concept that's easy to understand.

Right. So I.

So maybe key cases worth having. I mean, the fact is I, you know, occasionally machine generated things have complicated left hand sides and their associations. Human generated ones tend not to, they tend to be things like strings.

Okay, so I'm not sure. Oh, I see. One is using this key cases and the other is using key select.

Yeah, this is just showing, you know, in principle you can make key cases out of key select with match queue. But you know, there's some, you know, cases supports, for example, the transformation rules in the pattern which select doesn't really say I want to replace all of the instances, I want the association that has all the F of x's and replace the F of X with X.

Oh, so this is only pattern matching against the keys.

Right.

So this in fact is significantly less powerful than.

Position pattern.

Position pattern.

Yes, direct analog of key select and.

Right. And. Well, I guess. Well, I mean, if we supported some sort of. Maybe this isn't a problem. Right. But the moment you support, you know, transformations, then you risk collisions in the keys and you know, is. Is that what you want? Right. I mean, it's certainly potentially confusing whether or not it's, you know, the right thing.

Emerging function option by default it would just be take the most recent item like association normally does.

Sorry, in key cases.

Right. We're pattern matching against the keys. So if we allowed that thing to not Just be a pattern, but a rule then in the output. In the result, we risk colliding key.

Yes.

So we would need a merging function for the collision cases.

I think key cases worth having. I think it's easy to understand. I think like the other thing we just had, it's kind of cognitively easy. You've got key select, why not key cases. Now, I agree there needs to be a merging function. If we, if we allow this form.

Yeah.

That form is fairly exotic, but I don't see why we shouldn't allow it.

And then if you. If the keys were actually rules, you would wrap in key.

Or hold pattern.

Hold pattern.

Yeah, hold pattern.

Right.

That's what my thought.

Yeah.

Just like if you want to match rules with cases.

Yep.

Right.

Yes. All right. Counts merge.

So this was a. A suggestion from a while ago by one of our livestream viewers. It is a variant of counts that allows you to specify the expected. Values and give a default value.

Huh. In other words, I don't understand.

I don't understand that.

And if somebody puts a seven, it isn't counted.

The default value would typically be zero.

And almost, almost more as important is the order of the output matches the order of the second argument.

Right.

I find I always. After I get counts, I have to reorder it a lot.

Yeah. I would use this a lot there. I have a few cases where I would definitely use this.

I don't 100% love the name that was suggested.

No, but yeah, I mean, somehow this feels like it's part of the categorical data family. I mean, I have to say I'm not keen on this. I don't understand why the functionality isn't. First you do the. The breaking. Putting things into. I mean, the function that takes a list and has a set of values that are allowed and takes everything else to be missing. That seems like a useful function. This is then wrapped around that. See what I'm saying? There should be a function that normalizes a list by saying, here are the allowed values, here's the out of range values. Make the out of range values be. Be whatever you specify.

For example, trims, outliers, or.

Yeah, yeah. And I mean, I think you might even want. If it's numerical values, you might want a whole set of rules for what the missing stuff does. I mean, this is basically. Yeah, if. I mean, this is a useful function. If it's in a certain set, just pass it through. Otherwise missify it. Do you understand what I'm saying?

What might actually be the more general form of this is maybe give a default value to key take as an extra argument. Because then you could just run counts and do keytake with your range of 5 or whatever and then give an extra last argument saying what you want the default to be.

Yeah, except that this isn't keyed yet. I mean you could do counts key take of counts. Yes, you can.

But then there's a lot of other association types that aren't necessarily counts that you'd want to do this exact same thing with.

Right. But I. I'm saying I think the more general thing to do is we just have a function that prunes could even be called prune, possibly that prunes something down to a certain set. Okay. And if it's outside that set, it either has a fixed value or it applies a function to determine what to do with the. With the things that are outside the fixed set. So for example, I would say, you know, like prune or more like conform. Now more like prune actually prune this list to my set and that would give a failure object or something, but by default. And then here we have a function that's applied to everything that isn't in the set. I kind of like this function.

Is this not just. I mean, I suppose the three argument form maybe requires a bit of thought, but isn't. Isn't the two argument form just delete cases, you know, maybe with an alternatives at. At.

Yes, it is. So the case of the complement of that.

Oh, yes, you're right.

But the idea was. I mean, it's closer to keep strictly remove them.

Right. It would replace them with.

Yeah, you're right. It isn't quite prune. It's some kind of normalized type thing. I like this function. It needs a better name. What's that?

Yeah, a common case would be almost an inverse of delete missings would be insert missings or you know.

Yeah, exactly.

Identify outliers. I mean, that's maybe a bad method, but.

Okay, so I'm sorry, but I'm the. I mean, this seems like a fine function, but I'm not sure why we want to be inserting missings. Right. Because the missings. Right. The missing here is not from the.

Right.

It's out of range.

No, it's not. This missing in the examples that we see in front of us, the missing is not from being out of range. It's from the fact that there are no fives in the input.

That's why I was saying I think zero would be the more common case of using this. Because if you are dealing with counts. Do you want something that's not in there to be assumed to be zero?

Yeah.

Oh, I see.

So then if you're like incrementing values.

In there, you're not in the right.

So. So if you. If you look at the last. The input right before the bullet point, then the four which is not in the list is just counted as one, which I was actually going to ask about if that's really what we want, that things that are not in the expected set just sort of insert themselves into the results without any warning.

Okay, so there are two issues. One is there is a value not in the expected set and there are no values for a particular entry in this in the expected set. Right.

Yep.

Sorry, is. Is the expectation set keys or values?

There are no keys here. We're not talking about keys, it's just values.

Well, it's keys in the output of this particular function that's being in. In the particular function that's proposed at the beginning of the section.

But what we're dealing with here is we want this function to operate on values. It's just a list. The first argument can be thought of just as a list or maybe it's an associ. But that's.

It's we central dogma.

It.

The values of the list become the keys of the association. And I. I guess that's what's kind of confusing me there. If we're expecting to see range 5, but we count something 10 times, is that going to leave it as is or chop it?

No, that the.

Right.

The 10 would be a value in the output.

Yeah.

So there's.

There's two different things we're talking about. The first, the counts merge function that's proposed. There started a discussion about a more general function which would be this prune function and the prune function, you know, or. Or whatever we decide to call it is I have a list or a set of data and then I have my expected values. This counts merge is kind of a combination of that function and accounting function.

So. So how is there any relation here to key drop?

No, no, I think as a relation to key take, though.

Yeah, well, or is. Okay, key take just keeps a certain amount of keys.

And it will.

It takes a certain list of keys.

Yeah, but what, what it doesn't do is fill in something with default values if it's not in the original set.

Well, that probably could, but it, it is doing it based on keys. This is doing it. I mean, this is. So this is the value equivalent of Key take.

There's also an analog to look up, which does. Does, you know, just returns values, not an association, but it fills in missing things.

Yes, right.

You could do it with lookup and.

Thread, I guess, if you have an association. But I mean, this is operating on a list. So, for example, prune, look and lookup.

Drops the values that weren't in the expected list. So it wouldn't match the. What we have in the notebook for counts merge.

Right.

I mean, maybe we should call this function keep rather than prune.

Okay. So that there are two possibilities for what that could give. One is ab. Ab, which is essentially a select, and the other is a B failure. Three failures in a row.

I'm not sure it should be a failure. That's. That just sounds very aggressive.

Or maybe it's missing.

Yeah.

Or whatever. I mean, the default value. Whatever the default value is, which we don't know.

We could just say the default value is nothing and you get that first behavior. And then if you specify a default, you get the second.

Yeah.

It's interesting.

Yeah.

As long as we're only working on lists.

Yeah, true. Yeah.

Well, I mean, it's not the worst thing in the world to see a nothing in something else. And you know, what happened.

And then the second part is that question of what we do if your expected set is a B, Z and we don't have Z's there. Yeah.

What do we do?

Does the first argument have to be a list? A simple flat list?

Well, maybe not, but what do we do in this case here? Right. I don't think we can do anything other than because it's not keys. We're not leaving a space for the Z's.

Right.

Yeah. I think if we're keeping it structurally the same is the input. There's nowhere to insert A. This didn't occur.

Right. This is purely a thing for normalizing, conforming, pruning.

Yeah. So that, I guess you have an analogy with lookup is that lookup will give an exception if something is missing. This will give an exception if something is extra.

Yeah. Yeah.

If something is unexpected. So that's.

That's basically specifying what's allowed in the list, not necessarily that it has to have all those items.

Right, Right.

Yeah. I mean, I think if. For this prune function. Right. There can't be any special behavior. Now the question is, if we had this, you know, counts merge or whatever function, you know, what would it do in that case?

Or.

No, this case is fine. Yeah.

It'll just say zero isn't this prune just replace. Except goes to nothing.

Yeah. And doing the.

Yeah.

Or.

Or it's. Or delete cases. Except, you know, at. At the list.

Right.

Yeah, but you can also do cases alternative and then just flatten or concatenate the results.

We'd have to have alternatives around the accept or.

Yeah, no, I mean, it's a bit complicated. I mean every function can be expressed in terms of other functions, so the fact that it can be expressed doesn't particularly.

Right.

And.

Yeah, but I mean how many other functions? Because I think in this case we're only talking about combining two or three things.

I know, but the question is conceptually the name prune isn't great, but I think there is the possibility of a really good name for this, Like conform. But it isn't that either.

Well, it could be keep prune to.

If it's going to be prune, then does it makes sense to leave a bunch of junk in the middle of a list?

That's why. Well, if its default is nothing there, then its default is to prune.

Yeah, but the.

The general function isn't. Isn't really a prune in the case filter is what I. Or a filter or a projection almost.

Yeah, but this case. Right. Is. The case with nothing is purely alternatives applied.

So.

Yeah.

All right, we've introduced this. Let's. We need to marinate it. I actually need to go fairly soon here.

This is one of Rick's functions that he mentioned and I think it has a lot of merit. Basically a modernization of reap where instead of getting a structured result with positional tags that you have lost, it has a decorated association that has the results and then the various tags as keys.

Why doesn't have like the position where it's being said? No, it can't know that.

Yeah.

This requires more thought. I mean, I think that this is.

The benefit of this doesn't matter what the first item was that was sewn because you can just get things by key. Otherwise with reap, normally you would get the lists in the order that the tags are first seen. So you'd have to know the underlying code, what it was doing.

That none is the fact that the so didn't have a second argument. Is that correct?

Yeah, it is.

It's more interesting.

Well, the idea of a. Of a reap. So where it can give an association, there is an interesting idea. But are you sure there's no way to fit that into the argument structure of sow and reap.

Oh, I. And I mean. Right. You could throw None. In which case, how do you distinguish that? Right. I mean, one argument for so is not the same thing as.

Yeah, well, it's an argument against this. Okay. This is an interesting idea. Needs more thought and I'm trying to escape here, unfortunately. Oh God.

You know, if you need to escape, I don't think there's any problem with just saving these for the next agenda.

Fine, let's do it.

Okay.

One, one comment briefly is. I really like this, this last one, reap association or whatever it was called. I, I mean we, we really.

It.

It is something that has been lacking.

Let me understand what the point is there. The point is that you want to have tags.

Yes.

You want to use tags and sort according to the tags or at least.

Know what goes with what tag.

What.

What group goes with what tag. That's what's been missing. I didn't mean to keep you long, I just wanted.

No, no, no, that's a thing. But I mean, I'm kind of wondering whether there's a way I. I think.

I might have beat you to it.

Rick.

Chat wars.

Yeah.

You can come pretty close with reap with the three argument form, but.

Okay, fair.

It doesn't have that outer association which might kind of be good because the names result in sewn are kind of arbitrary.

Oh yeah. What I was showing in the thing I chatted was the default behavior. You have to know what tag is being sewn first to make sense of the output.

Right. That. That's, that's what I think is. Is not so great.

What do you mean? Because, because how do you. What isn't the result was the first.

If you try evaluate what I put.

In the chat, the result of the evaluation is the first argument of reap.

Right.

But to use the second argument, if you don't. If you don't have a third argument in your reap, you're just guessing.

So that what.

What sowed A and what.

That came first because that tag was sewn first. So you'd had. You would have had to know what the code was going to do. The underlying code to make sure.

Yeah. It's implementation dependent.

I don't even understand what it did. Why are the A's and. Oh, because they're tag one. Oh, I see. You have no idea which tag is which. Right?

Yeah. So if you replace tag one with tag two and vice versa, you. Yeah. You'd get them in a different order.

I have to admit this reap association makes decent sense to me. Although I wouldn't bother to have that outer Sowing result, et cetera, et cetera, et cetera. I think that's a mess.

I agree. I don't know why I thought it was a good idea back when I made this, but it probably should just be a list with the result and an association of the.

So really this is different from reap? Only in the sense that it is. It is getting things in an association, which makes perfect sense to me.

So it's basically the Same as in 47, but the second argument is wrapped in association.

Yeah, and that's.

But it's still function because that blank comma rule is weird, right?

Yeah, that's probably what I did in the implementation.

Okay.

Something like that.

Okay, but what do we do with the none?

Anything we put there can potentially be a tag is the problem.

Yeah, I know.

Oh, so reap catches both one argument. So reap blank catches both one argument and two argument sos, which is different from throw, throw and catch.

This is a good function. I agree. So I think we just have to solve the problem of what the. I mean, but by the way, how many arguments this crazy thing have? Reap has a lot. I mean, it's a pity that there aren't like named elements here of the reap output, which is what I think you were going for. But I think at this scale, you know, the more common thing is going to be I just want the stone tag, so to speak. I'm not sure we need a better version of none. What the heck do we do? What does pattern matching do when an argument is simply not there? What does it do?

Something sequency?

Yeah, it's. I mean it. Basically it's a crazy null sequence.

Right? Well, it's not literally right. It just. It just. It's just removed from the. Yeah, from the right hand side.

Technically that single underscore shouldn't match it. Right.

Well, maybe there could be just be two separate associations and that would avoid key collision.

Well, it isn't an association, it's just one case. Yeah, maybe what it is is it's a triple a list of three things. The result. Go ahead.

The unnamed ones and the rest.

Yeah.

Makes sense as a list because there would be no key.

That's possible. Let's ponder it so that we can make that work. Yeah, I mean, that's unambiguous at least. All right, I have to go. See you guys soon.

Bye.

All right, sounds good.

Thanks everyone.

Bye. Bye.