[Joker_vD]

Right, so you're essentially talking about how in e.g.

    class Parser:
        def __init__(self, text):
            self.text = text
            self.result = None
            # other inners state/context fields

        def parse(self):
            self.parse_top_level()
            return self.result

    def parse(text):
        return Parser(text).result

the free function "parse" throws away the inner context. When one uses parser combinators, there is no single monolithic Parser class which one may extend with whatever additional methods necessary (and maybe take some free functions as callbacks, why not); instead there are lots of smaller functions returning the leftover contexts together with the results, and you have to combine them somehow, together with free functions.

> without having to actually perform the parse until you need to.

I'd rather parse my input before starting semantic analysis on it. Although if you really want to have a one-pass translator, literally being a composition three functions, `parse`, `analyze`, `emit`, with no visible intermediary structures then yeah, this allows for it.

But I'd argue that's more complicated than having three non-entwined passes with explicit, designed data structures serving as interfaces between them instead of invisibly unevaluated thunks; not to mention the sheer complexity of doing everything in one go (why do people even claim the single-pass compilers are simple?)

[thosakwe]

You make a valid point about the added complexity of combining parser combinators with functors and other concepts.

Honestly, if I were writing a compiler, I would go with your approach as well.