I’ve just finished the first version of “Parsem”, a Parsec-like parser combinator library for Crystal. I wrote it mostly for fun, as a nice excuse to learn and explore Crystal, and perhaps to build some other stuff with in the future.
I personally love parser combinators for how little code is actually required to write new parsers for all sorts of things. Do note, however, that the resultant parsers are not necessarily performant for very large input sizes.
Along the way, I wrote a couple interesting (to me) macros, like curry and infer. It’s pretty neat that Crystal makes these sorts of code transformations possible.
It’s available here. Feedback, suggestions, etc. are welcome 
9 Likes
Nice! I also implemented curry like that for fun, just for me. I wanted to copy Ruby, because they also have curry. But in Ruby it’s even more magical in that you can pass any number of arguments, and it will keep currying. Like, if you have a proc that takes three arguments and you curry it, if you then pass one argument you can something that expects at most 2 more arguments. But if you pass 2 arguments you get something that expects at most 1 argument. Or, I guess that could be done with a type other than Proc. But maybe curry argument by argument is good enough. I’d even consider it adding it to the standard library (not sure how useful it is, but why not)
1 Like
Quick update! v1.1.0 now has vastly improved performance for large input sizes.
I finally figured out how to profile Crystal code (in Apple’s Instruments tool), and turns out the culprit was oodles of Array allocations due to slicing with #[]. Working with Slice instead provides a cool 120x speedup for the case in question.
9 Likes