search

rust-bakery / nom-bufreader

BufReader adapter for nom parsers
MIT License
9 stars 5 forks source link

Parser returns(including error type) need to be owned values. #9

Open cheako opened 2 years ago

cheako commented 2 years ago

This was impossible to figure out. The top-level parser should be forced to have Clone on its types, especially nom's default error type.

cheako commented 2 years ago

Fixes #3

kyzyl commented 2 years ago

I was testing out this project on an exiting nom parser and was was also confused by this for some time. I'm probably betraying my lack of understanding here, but why exactly is it the case that only the top level parser needs to yield a Clone type?

cheako commented 2 years ago

It's because the other parsers return a reference tied to the lifetime of the slice they are passed. When the top parser attempts to use that lifetime, the &[u8] that is created and owned by nom-bufreader, it breaks because the caller into nom-bufreader does not own the slice being matched against.

I think nom-bufreader needs to return the Vec<u8> it's matching against, this is perhaps the best/most nom like solution.

Edit: I now realize this leads to a self-referential type... The tuple being returned. Suffice to say, this is not easily solved except by changing core nom to have an owned return type for this case.

kyzyl commented 2 years ago

Right, I see. Thanks. That indeed seems sticky. Perhaps it requires a special BufferedParser type which is what this crate's parse requires, that just yields the bare type, not a tuple with the remainder buffer. As you say it doesn't seem possible to keep it compatible with existing nom types. It seems like Rust is highlighting here the fact that the concept of 'returning' the underlying buffer that is currently being streamed into is not well defined. Although maybe this is a problem that has been thought about elsewhere. I'm not that familiar with the particulars here.

cheako commented 2 years ago

I'm glad there is interest in nom as I don't have the knowledge to take on a project like this. For example, I don't know how bad(if at all) it would be to force all the return types to be owned values. I will be embedding a modified version of this crate in my own crates. With that, I'm interested to know if there is a community that could offer support with setting design criteria.

Having a super trait over nom::Parser sounds like the right call... Though I haven't needed to look closely at it.