You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rack Next is going to rely heavily on parsers. A decision needs to be made on what parsing library to use. Performance is most critical, but I'm willing to prioritise the readability and maintainability of one library, over marginal performance gains of another.
Also to consider, the parsing library should support compilation to plain Ruby to avoid it being a runtime dependancy.
The text was updated successfully, but these errors were encountered:
I propose to provide the use cases (a list oft entities) to parse in order to derive requirements. Then we could see if one of the following meets the needs:
I've used treetop and parslet, and dabbled in racc which kind of scared me off as it doesn't look very "fun" to use, but iI acknowledged it's quite performant and compile to plain-old dependancy-free Ruby. Regex can certainly be used for simple things, but whenever I've seen it used in place of a parser, it's normally been harder to maintain, and often you need to take shortcuts which don't meet the spec for the grammar you're parsing.
Rack Next is going to rely heavily on parsers. A decision needs to be made on what parsing library to use. Performance is most critical, but I'm willing to prioritise the readability and maintainability of one library, over marginal performance gains of another.
Also to consider, the parsing library should support compilation to plain Ruby to avoid it being a runtime dependancy.
The text was updated successfully, but these errors were encountered: