-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Update usage parser (potentially with nom or chomp) #350
Comments
From the one side - we can rewrite parser no As for me - I'm pretty much for rewriting :) |
Yeah I understand the new dep thing, but if we can make the code more readable, concise, testable, and performant then I'm all ok using a new dep. If we can do all the above by just re-writing the parser I'm good with that too. But I would imagine handwriting a new parser might be re-implenting things already solved in Also To be clear, I'm not really advocating using |
In all honesty using an iterator in the usage parser is silly, but I guess it made sense to me when I did it. We'd probably get way better performance using a real parser, which is what I'd really like to explore. Whether that's using something like |
Closed with #386 |
With nom recently reaching 1.0 I'm wondering if using would be any benefit to this project. Particularly in the test-ability, performance, and maintainability.
Because I'm very unfamiliar with it, but slowly reading through it, this may be slow going.
Perhaps initially evaluating on the from_usage parser.
To be clear, in order to be merged into mainline it needs to not impact performance at all (which I don't believe will be an issue), and must improve at least one of the items above.
The text was updated successfully, but these errors were encountered: