RegexParser | Regular Expression parser | Regex library

The two members of MyParser, expr and subExpr, must be initialized every time MyParser is created, but they reference each other. They are evaluated in order, and when evaluating expr subExpr is still set to null. A simplified version of this problem is:

Easy, just make the parser recursive:

You can use the following Regex which enforces anything else prior the digits then captures the digits:

As the warning says, now you should implement the hash(into:) function instead.

I ended up being able to solve my problem by removing the left recursion via techniques found in this answer. Below find the working code.

I had to think carefully about the transformations: particularly alternation.+ ^^ { _.reduce(_ + _) } and sequence.+ ^^ { _.reduce(_ + _) }—converting those back to the AST generator may be non-trivial (as the constructors for those require only a left and right). The repetition also bothers me a little, but without extracting a helper function it was the only thing to do.

Your parseExpression and listElements rules are mutually left-recursive (via parseOr). In my comment I've suggested that this probably wouldn't cause the stack overflow here because parseElement is tried before listElements, meaning that listElements would never be reached (which is another problem in and of itself).

However, since you're using parseExpression in a * loop, it will be applied repeatedly until it fails, which means that all of its alternatives will be tried in the end. So listElements will be reached and the left recursion does indeed cause your stack overflow. You can also see this from the fact that the stack overflow disappears if you comment out the | parseOr in parseExpression.

See regex in use here

The reason for the error is that line and eol are defined as normal class field vals, but they are used in lines before their definition. The code that assigns values to class fields is executed sequentially in the constructor, and line and eol are both still null, when lines is being assigned.

To solve this define line and eol as lazy vals or defs, or just put them before lines in the code.

The parser itself also has some problems. By default Scala parsers automatically ignore all whitespace, including EOLs. Considering that regexp .* without any flags does not include EOLs, line naturally means "the whole line until the line break", so you don't have to analyze EOLs at all.

Secondly, the lines parser as defined is greedy. It will happily consume everything including the final ##. To make it stop before end you can, for example, use the not combinator.

With all the changes, the parser looks like this:

The error message is telling you that you're pattern matching a list against the ~ constructor, which isn't allowed. In order to use ~ in your pattern, you need to have used ~ in the parser.

It looks like in this case the problem is simply that you discarded the value of intLiteral using ~> when you did not mean to. If you use ~ instead of ~> here and add parentheses¹, that should fix your problem.

¹ The parentheses are required, so that the following ~> only throws away the bracket instead of the result of intLiteral ~ "[". intLiteral ~ "[" ~> expr <~ "]" is parsed as (intLiteral ~ "[") ~> expr <~ "]", which still throws away the intLiteral. You want intLiteral ~ ("[" ~> expr <~ "]") which only throws away the [ and ].