Redo CONST evaluation and use the element string directly. #435
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This moves the CONST replacement up before we turn the elements into a single string. The advantage is that we don't have to worry about splitting the string properly to find the CONST names as the elements are already split for us.t
SteveMcNeill
approved these changes
Jan 19, 2024
RhoSigma-QB64
approved these changes
Jan 19, 2024
a740g
approved these changes
Jan 19, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I ended up taking #429 father and simply changed
Evaluate_Expression$to use the string of elements directly, rather than converting it from elements back to a regular string. This has the big advantage of removing all the ambiguous situations we had to account for. It additionally made it fairly straight forward to add inStringsupport, meaning the oldevaluateconst()is unnecessary and could be removed completely. Combining numeric and string support also meant I could fairly easily add support forCHR$()andASC(), which are nice additions.To facilitate testing I moved a decent amount of functions and definitions out of
qb64pe.basand into separateutilities/files. These were largely left unchanged, beyond any additional utility functions I added (Ex. there's many newelement*functions that make working with the element strings easier).For
Evaluate_Expression$itself, the base design is still there (search for parens and evaluate starting with the innermost set), but to make the elements work and also fix #196 I ended up rewriting the parser to use a recursive-decent parser, which works fairly well. Because parens are not evaluated as part of the recursive-decent parser it doesn't actually get all that deep as far as function calls go.Fixes: #192
Fixes: #196
Fixes: #359