rust-yard
rust-yard copied to clipboard
Custom functions and variables
Heya! Just stumbled upon your library and first I wanted to say nice job :+1: Looking good.
I have a project I would like to implement this in, however I would need two more features that would make it more usable for me:
- Custom functions
- This could be implemented with a
HashMap<&'static str, fn(&stack) -> f64>
- This could be implemented with a
- Variables
- In my application the user will input a calculation and this will have to be evaluated with the values put in correctly. This could also be implemented with a HashMap, akin to 'if it has no parantheses it's a variables' and on resolution you replace the value using the user supplied HashMap.
Is this something you would like to see in your project as well? If yes, I wouldn't mind sending in some PR's in the near future.
@simon-whitehead Hey, I would like to see custom functions in this as well. I'm thinking about using this library in my project, too.
Hi there @matthiasbeyer and @TheNeikos .
I am more than happy to accept PR's if you plan on spending some time working on this library. If there are any improvements or additions you want to make then I would certainly appreciate it!
Custom functions and variables are certainly on my list of features to implement. Now that I know this library is of actual interest to some people I will start implementing them as soon as possible! If you're keen on implementing them yourself do let me know and I will hold off on doing it myself.
Thanks so much for raising this with me! :smiley:
Alright, I will tackle the variables then.
Okay, I've been trying to wrap my head around the code a bit and I think I will clean it up before implementing the features as there are still some unhandeled edge cases.
Please do. I am still learning Rust and "The Rust Way" so it is very likely that there are some places to clean up in this code (especially since it was my first proper dive in to a Rust codebase).
I didn't want to push any changes because I figured you might make some big sweeping changes whilst implementing variables.
As a side note: perhaps requiring variables have a prefix simplifies the implementation. For example, max(@someValue, 50).
No the implementation itself is 'easy', you just get yourself an identifier and check if the next character is a (. If it is, it's a function (perhaps), if it's not then it might be a variable.
If you would prefer there to be an @ infront that would work as well.
Regarding the things I would clean, I plan on making it a clear seperation of the steps. So one does not get easily confused of the names of the tokens.
Then I would remove the 'match all' patterns as they make the code less stable. Since if you add something new to an enum you lose the 'type' safety of that case being handled.
I'd vote for variables names without any prefix. If is just nicer syntax-wise, IMHO.