From what I can see, parser combinators are equivalent to scannerless parsing. I do not see this stated in implementations of scannerless parsing page, nor in the parsing combinators page, neither in the google generally. But, it seems they are. I didn't code the low-level rules separately or using different syntax than higher order ones.

Am I correct that parser combinators are simply scannerless parsing? Or is there a difference that I am overlooking?

  • 1
    $\begingroup$ Beats me. You'd have to ask "everybody" why they don't. $\endgroup$
    – vonbrand
    Dec 29, 2015 at 21:24
  • $\begingroup$ @vonbrand Why don't you do that personally? Answer for yourself. $\endgroup$ Dec 29, 2015 at 21:34
  • 2
    $\begingroup$ I don't think questions "Why doesn't everyone say X?" are likely to be useful or suitable for this site format. See cs.stackexchange.com/help/dont-ask: specifically, 'avoid asking subject questions where there is no actual problem to be solved: “I’m curious if other people feel like I do.”'. (See also “______ sucks, am I right?”.) I don't see any problem to be solved here. Can you think of any way to edit the question to make it more suitable here? $\endgroup$
    – D.W.
    Dec 29, 2015 at 22:42
  • $\begingroup$ @D.W. So, basically, asking about adopted practices. Understanding "why?" is bad idea. It is a bad kind of knowledge and people cannot benefit from it. I should not know why seemingly scannerless parser, de-facto standard in functional programming, is not attributed to that category. Nobody should know that. Nobody will tell that for this reason. Seems like the answer. $\endgroup$ Dec 29, 2015 at 23:47
  • 2
    $\begingroup$ I've edited the question to ask a technical question, rather than (a) an argumentative question that seems to call for debate (not suitable for this site), or (b) an unanswerable question about why others don't say something (not answerable; you'd have to ask them). Please check that the edit reasonably reflects the sort of information you'd like to find out here. $\endgroup$
    – D.W.
    Dec 30, 2015 at 0:38

1 Answer 1


It may be that both are commonly used together (that's the kind of estimation which is very sensible to perspective effects), but they are in principle different.

Scannerless means that the parser is directly fed the stream of characters instead of getting tokens recognized by a scanner with white spaces and comments removed. You can use whatever kind of parsers you want to parse the characters.

Parser combinators is a way to build a parser for a complex language from parsers for simpler one. The stream of symbols on which the bottom parsers are working may be a stream of tokens recognized by a scanner or a stream of characters.

That said, it is possible to hold the point of view that a scanner is a parser combinators (combining regular expressions) and thus that parser combinators are always scannerless parsers (if you are using different tools for both, that seems a quite abstract point of view). But even then, it is possible to have scannerless parsers which are using other parsing techniques.

  • $\begingroup$ Cool. I just guessed that parser combinators are a subset of scannerless but you say that the opposite is also seems resonable. For this reason, it is even more surprising that people do not notice parser combinators are notable implementation of scannerless idea. $\endgroup$ Dec 30, 2015 at 2:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.