Parser working incorrectly

[fluid walrus]

Hello everyone. I come here with an issue. I'll just refresh your memory if you don't remember the subject of my project; basically I'm working on a chemistry simulator where different reactions can be made. It went good so far, until it came to parsing. To be exact - parsing the coefficients. Note that coefficients are the numbers before the compound, for example, __2__H2O. I'm storing those coefficients in two dictionaries: one dictionary for reactant side, and second dictionary for the products of the reaction. So, when it comes to the reactant side, AKA 2Na + 2H2O -> 2NaOH + H2, the dictionary would return Na: 2, H2O: 2. And it does that. Just one problem: I noticed that the parser doesn't stop when I need it to, that is on the arrow symbol. Instead it proceeds until "Na". Since such element already exists in a dictionary, It simply throws an exception. In order to avoid this I just made an if so when there already is a Key in the dictionary with the same name it would break the loop, but as you might have guessed, it doesn't fix the problem. So, when it comes to the product side of the equation, it actually doesn't add anything to the dictionary. I have no idea what I'm doing wrong (except for the fact that the code is terrible - I will optimise it the moment I finish working on this function).

Code: https://pastebin.com/hQ4KrGNb

Any kind of help will be appreciated.

[fluid walrus]

h

[native ether]

I'm only giving it a quick overview but from a design p.o.v. it's worth considering Tokenization

Tokenize anything you'd consider valid and your parser will advance through a list of available tokens. If - should always be succeeded by a > then you'll have a -> token. If - can also be used to subtract, but requires a subtraction value token then the parser can be set to follow that and report any inconsistencies out there. I'm only mentioning this because it sounds similar to how a compiler is built. Lexer (tokenizes) and parser

I apologize if it's way off point for what you need.

[fluid walrus]

well I'm not using -> but an arrow symbol. I just used -> for it to be faster

So, I should rewrite this completely?

@native ether

[indigo robin]

Peeking in to say that I absolutely second this. For something as complex as an equation parser you need a tokenizer so the whole system is maintainable and easily expandable.

string --[tokenizer]--> List<Token> --[parser]--> C# objects (class instances)

That is all for me, good luck soldier o7

[native ether]

I will clarify however @fluid walrus that a Lexer, Parser that me and SPR2 are talking about is not just a weekend project. If you're unfamiliar with this it might very well burn you out.

A simplification of your current situation would be:

If you want the functionality you have now, and little else, and you know this, and you're almost there. Stick with it. It would be dumb to throw it all away for the "potential" for more. Having said that, what you're doing is going to lead to a dead end soon enough, and you're starting to reach that limit already given the problems you're currently facing.

A proper Lexer / Parser combo will be scalable, robust and it's what is actually used when building compilers and general language parsers. If you do want to bulk up your current version with a lot more stuff and possibly an even more complex "language" it's a must-do.

On the flipside, if this is what you want, catching it early before you invest several months / years into it and going "ah shit" would have saved you a ton of trouble. It has been known to happen. Some very old corporate projects end up like that unfortunately.

Apologies for the rant, just wanted you to make an informed decision. But don't feel bad about sticking with "less than ideal" code. Sometimes that's exactly what's needed to get something shipped out and done with. Should still feel proud about it.