:: krowemoh

Thursday | 26 DEC 2024
Posts Links Other About Now

previous
next

Writing the EVALUATE Function

2023-06-15
basic, template-language

I wrote a render routine that could I think is relatively simple. It goes character by character building up lines of BASIC and HTML. The lines of BASIC are scanned in and then parsed.

The parsing step is where I read in the statement that is being run and decide what parts of that statement are the expressions. This means that I can now start looking at the OPEN statement like:

OPEN EXPR,EXPR TO VARIABLE.NAME

Now that I can do this, I can call a function that will evaluate those expressions. All it needs to do is given some string, give me the evaluation of that string. I want the final value of the entire string.

I realized that I could use my postfix notation for everything now. I simply need to take the expression and convert it to postfix notation and skip breaking on the angle and square brackets. This way I get a postfix notation that will have all the tokens good to go.

Then I could calculate the result of the postfix string easily. I would add in cases where if the value wasn't a string and it wasn't a number then I can look it up in a variable table. If it was in the variable table, great, if not it will be blank.

The harder step was to add support for the angle, square and paren brackets. This required figuring out strings that make up a token containing these characters and then I would call the evaluate function again. This would be recursive.

TEST<SOME.VAR<2,>1,2+3>

This has multiple expressions in it that need to get processed before I could actually pick off the right part of the TEST variable.

I think I have a pretty solid EVALUATE function now which I'm pretty happy with. I imagine there are edge cases and weirdness everywhere but I think this abstraction was worth it.

I took my infix to postfix routine and my tokenize routine and my evaluate routine from my {previous attempt} [My previous attempt was actually not bad, just went the wrong way at some point, though this may also be the wrong way.] and combined them all into one large EVALUATE function. I think this is the best of all worlds as it limits the amount of files I need for my RENDER program. I don't think there is a good way to keep this logic in same file as my main RENDER routine but maybe some day.

For now I can EVALUATE expressions and BASIC functions on demand which is quite nice. The next step is to go back and add this code into my RENDER routine.

I also broke and used my {hashmap } [I didn't realize how much I would lean on these abstractions] routines that I wrote as handling multivalue will be simpler if I can trust it to my hashmap instead of doing the raises and lowers that would be required to get a LOCATE statement working.

Clocking in at 670 lines of code in my EVALUATE function. There is a chunk of code that I'm not happy with that I will need to revisit.