The very same patterns that define "packrat-like" parsers (which share a strong relationship to the monadic and "arrow-adic" parsers) can be extended to define things like DFAs and semantic pattern matching. And languages with support for rich, somewhat lazy pattern matching like Haskell and Prolog wipe the floor with eager languages without (e.g., C), which is ideal for semantic analysis.
While not an "authority" in the subject, I've spent a lot of time working with some very skilled folks in the field of NLP, Linguistics. Most tools they used (in our case licensed from X/PARC) had C underpinnings for performance, but ultimately consumed specifications that were very much like Prolog or Haskell in character. Talking to some of the linguists who wrote those tools suggested that had GHC existed (or Allegro or a fast prolog been cheaper) then they would have been much easier to write in those languages.
I'm afraid I can't say much more beyond what I have without talking out of my rear. But you can read about X/P's XLE project here: http://www2.parc.com/isl/groups/nltt/xle/
The very same patterns that define "packrat-like" parsers (which share a strong relationship to the monadic and "arrow-adic" parsers) can be extended to define things like DFAs and semantic pattern matching. And languages with support for rich, somewhat lazy pattern matching like Haskell and Prolog wipe the floor with eager languages without (e.g., C), which is ideal for semantic analysis.
While not an "authority" in the subject, I've spent a lot of time working with some very skilled folks in the field of NLP, Linguistics. Most tools they used (in our case licensed from X/PARC) had C underpinnings for performance, but ultimately consumed specifications that were very much like Prolog or Haskell in character. Talking to some of the linguists who wrote those tools suggested that had GHC existed (or Allegro or a fast prolog been cheaper) then they would have been much easier to write in those languages.