-
Notifications
You must be signed in to change notification settings - Fork 17
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
Remove the tree-only --> overload #80
Comments
I’ve run into this, too—and IIRC this impedes the use of Thus far my workaround has been I can think of a couple of potential resolutions:
What do you think? |
I would lean toward 2. It enables I would also be hesitant to add more custom operators over the existing set. Instead I would favor a few extra named operator functions for common parsing patterns. Although those deserve a separate issue. |
I perused the open issues and you've already noted the pain points I've hit so far. |
Yeah, I’m leaning that way myself. Going to change the title of this issue to capture that. |
I was experimenting with Madness and found the overload of
-->
makes it a bit cumbersome when the mapping doesn't require the original input.Is there a better approach for this sort of thing when parsing keywords, etc.?
The text was updated successfully, but these errors were encountered: