> - Is this a valid approach?
It is possible that your Parsec lexer will need to see the entire
input before it delivers any tokens at all to the Happy parser. This
might cause a space problem, depending on how large your inputs are
likely to be.
> - What is your workflow on parsing complex data structures?
I usually write a lexer by hand, as a little state machine delivering
a lazy list of tokens, then pass the tokens as the input to a grammar
built from parser combinators. For larger inputs, I use lazy parser
combinators to avoid space leaks.
> - What about performance? Since my project is going to be an
> interpreted language parsing performance might be interesting
> aswell. I've read that happy is in general faster than parsec, but
> what if I combine both of them as I said above? I guess that parsing
> a simple list of tokens without any nested parser structures would
> be pretty fast?
Parser combinators are rarely a performance bottleneck in my
experience. However, relying on parser combinators to do lexing often
slows things down too much (too much back-tracking).
Regards,
Malcolm