-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom functions and variables #6
Comments
@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! 😃 |
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, |
No the implementation itself is 'easy', you just get yourself an identifier and check if the next character is a 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. |
Heya! Just stumbled upon your library and first I wanted to say nice job 👍 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:
HashMap<&'static str, fn(&stack) -> f64>
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.
The text was updated successfully, but these errors were encountered: