 Here you don't, you don't need that. I mean, I'm, I'm fine with the code you wrote, but you could use that instead of unwrapping it and then wrapping it again, just propagate it. This you don't need if you could just say or self-radix equals 10. Your input is already a string slice. So this itself could be a string slice instead of building a brand new string and putting characters into it. You could take a slice of the input that would avoid creating a new string. So you have this if, if break, break pattern and I think you can do not like you can't can merge those. Can you? I don't know if you can do parentheses there. Can you do parentheses? Can you do it like that? I don't know if you can do it like that. But if you can do it like that, maybe do like that and can this be a while loop? If you can do that, then this could be a while loop, right? Does, does Rust have a while loop? You can do while, while of this crap, there you go. So we checked after the stream and apparently the while let and feature doesn't really work. First you need to enable the experimental let chains feature. But once you do that, it accepts the syntax, but it doesn't like you using the variables that you declare and let outside the let. So maybe in the future, it'll work. Right now this tip doesn't work, at least in general, maybe in your case, it'll work. I don't think you want to do that. This is making a copy of the token. So it's making a copy of all this crap. I would make this a static reference. So it'll be a pointer to one of these globals instead of copying all that junk because you don't need a fresh copy of this stuff. And then this could be static as well. You really shouldn't be using strings for this stuff. You're going to be doing string comparisons and those are, that's like JavaScript level speed right there. You don't want to give Rust a bad name. So enums, enums would be a better option. But what I would probably do is not use a hash set at all. I would make a struct that contains just a bunch of Booleans, Boolean for identifier, Boolean for number, you can hear any plus, etc. And then this would turn the Booleans on. This would turn the Booleans off and there's no string compares. There's no hashing. There's no dynamic memory allocation or anything like that. Maybe you wait and do bit operations. Probably not. If you do you wait and bit operations, then if you think in the assembly level, a Boolean is just an address that you read and write to a single instruction to manipulate the Boolean, turn it on or off or read it a bit operation, I guess it is a single instruction as well. Oh, okay. So yeah, I kind of like your bit idea in one operation, you can set a lot of bits. It's a better idea than a bunch of Booleans. Do you have tests for this? Where's your test? Is it at the bottom? Evaluator? No tests. This is like the easiest thing in the world to test. Two plus two is equal to four. You'd bang out so many tests for this thing. I mean writing error tests are a bit more annoying. It's in your main? No, that's not a test. This is a test program that you manually run and you manually verify the results but there's nothing saying that this equals whatever it's supposed to be. There's nothing checking that for you. So when you run this program, it'll print out 18 but you're like, is that the right answer? I don't know. If you write a test script that just checks between different combinations then you don't got to second guess yourself. You definitely deserve some tests. These kinds of things, super easy to test with automated tests. You just bang out like 50 tests, super easy. The test would be short. Two plus two should equal four, Ryan. Oh, that was all an operator. Jesus Christ. What I would do in an ideal world, I would split this up. I would put all this code to handle operator. I would make that in a function and if I put in a function, I probably need to give it all these variables. So instead of giving all of these variables, I would make a struct to hold all these things. So I'd make a struct for all this then add some functions on that struct like parse operator. And maybe instead of continue or whatever or break, you might do a return. It might be easier to follow and be less indentation for sure because like, you're pretty deep here. It's worse than Yak output. If you spend some time on it, I think you can improve the code. It's just like you just got to put in the effort. This is kind of repeated over and over again. It's always evaluator error and then some message. You could make a function for that to make it a one-liner. Just like compress the code, make it easier to skim through Simon operator. If you don't have it, insert it. When would this ever be true? I don't think this code would ever run. I think it would have to exist because that's the whole point of this code up here. Make sure it exists. If you refer to it. So I would turn this into an assertion, assert that a key definitely exists. Same here and there got to look how to assert. Assert is just assert, I don't know, 2 plus 2 equals 4. And if it doesn't happen, your program crashes. So it serves as documentation. You can make a get variable function that returns an option of a ref to variable value. You can do that. And then you would have a fun get variable myself, my flow, much nicer. Oh, you need the token. Why did you write it like this? That could be written like that, right? Whoa. You got an equals if here. I would say it's probably better to write this using match. I would prefer to see match here. So match, number, no match self values, pop. So if it's some number, number. Otherwise, it just feels more familiar to me anyway. Your style is fine. Or there's okay or. Yeah, you can do that. So this be okay or this error, question mark. It's even fancier. So that says do the pop if the pop succeeded. If you got some, just wrap it in okay. It did succeed. Give an error. Actually, I don't need that. Then if you got the error return. So it's a shorter code by a little bit. You see, I don't come up with the best idea the first time around. I think you could do the same thing here. You have the same pattern here. So overall it looks good. It makes sense, structured how I would expect a parser and evaluator to be structured. A lot of typical code and lots of it dense. Yeah, I'm sure you're able to factor a lot of that out. Monkey toilet, huh? Good name. Good name. You got better tips than me? Comment down below.