-
Notifications
You must be signed in to change notification settings - Fork 92
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
Overload operators as parser combinators #32
Comments
This is definitely something I'm in favour of, especially implementing parser for strings and character literals. Anything that makes the syntax easier to write and understand would be excellent, in my book. Overloaded operators would be cool, but if it requires a great deal of changes internally, it certainly doesn't have to be a priority. I really like the use of operator overloading in the Scala parser combinators library, but making it work in Rust could be a bit of a struggle. |
@hawkw I might actually have been a bit to optimistic about allowing strings and character literals as parser. It would work but they would need do be specialized to work on only a single type of input stream (probably &str). It may still be a bit of useful sugar but it does feel like something that would be easy to trip up new users on. The changes I was thinking of to make operator overloading possible is to introduce a newtype which all parsers return so instead of |
@Marwes: Ah well. I haven't ever had to use pass a |
Passing parsers by &mut is pretty common for combinators since they can't move the parsers they own (see And). It would be possible to just add a method on |
Tuples as a sequencing parser are implemented in f8c15a2 (0.5.0). With RangeStreams (#42) I a am a bit more keen on the string literal overloaded as a parser as the Operators won't happen for 1.0 as it would break everything and require a lot of rewriting. |
For reference, I like how |
Tuples are the equivalent constructs in
Still torn on allowing the use of literals directly as they can only work with a single stream type which may make that those streams seem ( |
In nom, you can name the fields you want, while with the tuples you have to use |
True. The idea is to use pattern matching to name the fields you want. I suppose it may be clearer in code to put the names as close to the actual parser as possible though (as nom does). It is pretty low priority for me though. I'd be happy to accept a PR for such a macro if you feel inclined to add it. |
@Yamakaky struct_parser! were added which makes it possible to name the fields of a sequence. I don't see it as worthwhile making As for overloading operators. This would be an extremely invasive change and in the end all it would give is the ability to write So as a conclusion I will close this issue |
Since all parsers are currently functions or methods I find that large parsers often become a bit of a word soup. Large chains of parser can become rather hard to read. I have some ideas for what might be useful to implement which I document below.
Tuples
Tuples could allow parsers which should be applied in sequence to be written as.
Strings and character literals
Strings and character literals could implement parser directly allow them to be written without
string
andchar
.Use std::ops::* traits
The most likely candidate here is overloading
|
to work the same as theor
parser. Unfortunately this won't work directly without changing the library rather radically since it is not possible to implement it as below.This will not work since A and B due to coherence (A and B must appear inside some local type). The same applies for any other operator.
Since all of these could be seen as being to clever with the syntax it would be nice to have some feedback on which of these (if any) that may be good to implement.
The text was updated successfully, but these errors were encountered: