 I was playing around with something just as a little experiment. There's an alternative programming paradigm known as goal direction, which has quite a few really useful features of it, but like anything, that doesn't mean it's all good. There are a few issues, and this may be lack of an optimizer or something, so don't take it with too much salt. But what I did, you go into here where you can see, normally speaking, you can only write a single comparison, and you have to write the other comparison. What goal direction allows you to do is shorten that out to just this. Now that's just goal direction in this context. There's other goal direction stuff, but I've implemented it. This works. Just a second, one little quirk is that you have to use parentheses for everything before the very last one. That's got something to do with the parser, but this does work. I think that's pretty cool. However, like any feature, just because it's useful and involves a little bit less writing doesn't necessarily mean it's a good idea to use it, because oh my god, that is absolutely terrible. And I think, I don't think, I know why this is so bad. It's implemented using three additional comparisons for that operator. One, the very first one you would expect to be called, so this would be the comparison at the absolute left of the chain, except two integers, and returns an access to an integer. The reason we do this is in goal direction, you're not concerned with, I mean you still are, but you are also concerned with the successor failure. That's really what drives everything, is success versus failure. So how I'm defining things here is that with an access type, you can have it point to null, and I'm using the null as the fail state, where any valid integer is the succeed state, along with what actually needs to be passed to the next part of the chain. So then, because this actually passes an access to an integer, we also need two other things that both accept as the first parameter, the left, another access to an integer, and on the right just an integer. The right is always an integer for ease of writing things down. So this one also returns an access to an integer as the middle part of the chain. So this is the one that would repeat over and over again for very long chains. And at the very end of it, because you would have been passing access to integers across the entire thing, you have one that accepts the access to an integer and then just the integer and returns a boolean. This is the one that returns the result that the if statement then works with. There, this isn't great. This check would be done anyways, but then we're dealing with copying a value over and passing around the pointer to it. Here we actually have two comparisons. Luckily, this is a short circuit. So if this one doesn't pass, it just goes straight to here. But in the case of this actually passing, which is going to happen most of the time, you have two comparisons being done. And those aren't the least expensive operations in the existence. And so you also have the creating, copying a value and passing around the pointer to it again. And these add a lot of additional work just for slightly better syntax. So it was cool to know that this could be implemented, but this performance is terrible. Absolutely terrible. There's one thing I can try. Not like it helps all the time, but maybe it's worth putting in there. And I have not done this yet, so I have no idea how well this will work. Yeah, so that's a terrible increase.