CODEWITHSUNDEEP
parsingscalacoding-styleformatting
nnythm
nnythm

Reputation: 3320

What is the proper way to structure Scala parser combinator code?

Because the Scala Parsers library requires that you subclass Parsers, which leaves you with a specific Parser implementation in the end, it seems like you can't really separate it out into multiple classes or objects, unless they are inside the scope of the class that originally subclassed Parsers. What is the proper way of dealing with this, so that I don't have to just have 50 lazy vals in a row?

Upvotes: 1

Views: 173

Answers (2)

Daniel C. Sobral
Daniel C. Sobral

Reputation: 297155

Personally, I think the way to do it is keep all in one class or, if it makes sense, make a single inheritance hierarchy to expand upon concepts, just like JavaTokenParsers extends RegexParsers which extends Parsers. Also, use of tokenized parsers helps a bit, by splitting lexical from the grammar.

Other than that, keep it in one place: splitting a grammar makes for a nightmare of understanding. All the rest -- the AST classes, and the code that operates on them, need not be kept with the parser.

Now, if that really isn't to your test, you can split them in traits, and use self types to create the necessary dependencies between the traits. You them just make one big class (or object) which inherits from all traits.

Upvotes: 2

DaoWen
DaoWen

Reputation: 33019

You can split the different components into traits extending the same parent Parser type, and then mix them together to create your final parser. Obviously some of the parser combinators will be dependent on others, but at least the basic parsers (e.g. terminal parsers) could be factored out this way. You probably don't want to split it into too many different classes/traits anyway otherwise it could get very hard to analyze what the parser is doing if the code is split across too many different files.

Upvotes: 1

Related Questions