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
Explain why Copy is required for a type specified %parse-param #404
Comments
It is theoretically possible that it could be relaxed such that %parse-param could allow of an One of the things that makes this difficult may be the pattern matching involved in generated code, and the difference between FunctionParamPattern and Pattenrs. Copy patterns are fairly easy to implement without actually parsing the |
It would be nice if it supported Another possibility for your case might be to use interior mutation: so you could pass a type |
I guess that
whereas for
|
To some extent, the current design reflects the fact that I always write parsers that bubble state up rather than mutate state: honestly, it didn't really occur to me to deal with mutable state! Could lrpar be adapted to deal with mutable state? I guess it probably could. I must admit that I don't think I'll be the person who does that though :/ Sorry, that's not a very satisfactory answer on my part! |
I personally prefer to program purely functionally, but for performance I've been collecting some things during parsing mutably, which is very cheap when using a The other thing I want to do, where mutable state seems particularly sensible, is to catch semantic errors during parsing and log error objects into a |
I don't mind having another look at it, though I can't promise I'll be any more successful than last time I attempted to do so. The primary difference being in these 2 commits, where we went from accepting multiple named arguments to a single named argument. So, if we can in fact go with the simpler single named argument approach it may well avoid a lot of the difficulty I encountered in my previous attempt. As such I think there is reason to hope that much of the difficulty I'd previously encountered can be avoided. |
If it is doable, that would be great! |
It might be useful for the book to explain briefly why Copy is required for the type specified in
%parse-param
. This restriction has led me to have to pass in mutable state using a layer of indirection with&RefCell<State>
and repeatedly usingborrow_mut()
in actions, so I wonder if this is really necessary.The text was updated successfully, but these errors were encountered: