parsing is absolutely the sort of problem for which functional programming excels. if you think about it, there is no time dependence, no need to respond to external inputs, no concurrent access to mutable data, none of the things that would make pure functional programming a constraint rather than a help. all your are doing is writing one conceptual function of the form output = f(input), and that transformation is in turn made up of smaller transformations that can be written and tested independently, and then composed together to build up the solution.

now it might still be a little harder to do this sort of thing in haskell, which is aggressively pure, simply because some algorithms are pure from the outside but have internal steps that involve mutating data for efficiency. but racket is not a pure functional language; if you need to, say, transform an array in place rather than take an array and return a new one, it will not stand in your way. the difference between racket and, say, java, is not that it enforces functional over imperative programming, but that it makes functional programming a lot easier, and fp has a lot of powerful tools in its toolbox for tackling this class of problem.