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
Right now, parsus offers variety of methods to accomplish almost the same task. e.g. repeatOneOrMore vs. oneOrMore
As parsus' API is mostly undocumented and has to be discovered by type-completion, it would be helpful if the "right" methods were more obviously promoted in their context.
Using the @DslMarker would allow separating the ParsingScope from other scopes, and potentially forbidding to call oneOrMore declarative combinator in favor of an imperative combinator repeatOneOrMore. This, however, may not be desirable.
Even though using oneOnMore-like combinators inside the parser { ... } blocks is very inefficient, it could still be useful for prototyping. The alternative would force users to always use procedural combinators or to declare named declarative parsers outside the ParsingContext scope.
Having said that, I will play around with this a bit more and figure out if this actually improves discoverability.
Context: I'm porting an existing handwritten parser to use parsus.
Right now, parsus offers variety of methods to accomplish almost the same task. e.g.
repeatOneOrMore
vs.oneOrMore
As parsus' API is mostly undocumented and has to be discovered by type-completion, it would be helpful if the "right" methods were more obviously promoted in their context.
Kotlin offers a
@DslMarker
annotation for type-safe builders that is designed for this situation.The text was updated successfully, but these errors were encountered: