The generalisation itself is easily optimised away by the compiler, but I'm also tracking more info than slices do because error generation, which is costing cycles but is just as important as parsing.
Conversation
The tension between good errors and speed is very real.
1
Attoparsec and Trifecta demonstrate this nicely in the Haskell world.
1
I'm curious if you have to CPS all the things for speed in rust.
1
I doubt I'll go anywhere near exploring that, I'm just writing a parser for proc macro token streams, not an HTTP parser for high load servers or anything. My only benchmark is "compile faster than lalrpop." 😊
1
2
Ah, cool! That definitely falls in the slow with good error reporting category.
1
This Tweet is from a suspended account. Learn more
Not afaik but that seems like a good idea.
1
I have a strong suspicion that cases where you need that kind of performance tend to coincide with cases where "no" is an adequate error message, though.
2
1
This Tweet is from a suspended account. Learn more
Ooooh! Using effects and handlers for this seems fun. Might be handy to have good, guaranteed handler fusion for this though. 🤔 Also might be tricky in Rust (but perhaps another language might be able to do it?)
I wonder if somebody could do something terrible with the iterator pattern that could do something similar. 😬


