Skip to content
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

Suggestion: reduce need for spaces #26

Open
wtross-eg opened this issue Sep 12, 2021 · 1 comment
Open

Suggestion: reduce need for spaces #26

wtross-eg opened this issue Sep 12, 2021 · 1 comment

Comments

@wtross-eg
Copy link

wtross-eg commented Sep 12, 2021

I find it somewhat annoying that I have to write 3 4 * instead of 3 4*. I know that clac uses sdssplitargs(), which needs whitespace between tokens, and that any enhancement needs to be unambiguous for both the code and the user. I propose the following solution:
Every token output by sdssplitargs() is examined first in its entirety, as it is now, and then, if it's not recognized, it is split into a head and a tail in a loop, where the tail is 1, 2, 3... characters long, until the head is recognized (or until the head would be empty, in which case everything is discarded). As soon as the head is recognized, it is processed, and then the tail is handled in the same way (cyclically or recursively).
E.g., if the input is 2pi* (supposing pi is a word): it is not recognized, so 2pi is tried (the tail being *), then 2p (with tail i*) and then 2, which is recognized and processed. Then the tail pi* is not recognized, so that pi is tried, which is recognized and processed, and finally the tail * is recognized and processed.
In other words: tokens are parsed in a "greedy" way, with backtracking.

@wtross-eg
Copy link
Author

wtross-eg commented Sep 12, 2021

I see that in the code head and tail are already used for the list of words, so it would probably be better to use different terms. E.g., tokenhead and tokentail, or arghead and argtail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant