Configurable post-processing

[andrew-lei]

From discussion on #9:

As I've mentioned, I think it would work well as part of a post-processing step that would allow a user to perform more general sorts of manipulation on the intermediate bits. So the post-processor should be a function either [Output] -> [Output] or [Expr] -> [Expr]. I'm leaning towards the latter because I think it would allow for more general manipulation of the structure (for instance, to hide everything in certain Parens).

I was thinking one way to do this would be to perhaps have a constructor that contains the parsed value and either the type information (string literal, number, datetime, etc.) or the colour.

It might make more sense for the new constructor to hold the type name as a string and the data. That way, the same post-processor could be used no matter what colour it is.

I'd imagine for the two colour modes we could have the lazy string parser which would preserve current behaviour, with the exception of highlighting parse errors (non-existent escaped characters) in red. Should a lazy string parser (or any post-processing parser, for that matter) be used by default for NoColor? It would not be possible to highlight errors as red. Leaving it off default could prevent mistakes and anyone who wants it can easily enable it. But I feel like it's also unlikely for non-existent escape characters to show up in practice anyway.

[andrew-lei]

Should the post-processor be a monoid? Something like this:

newtype Postproc a = Postproc ([a] -> [a])

instance Monoid (Postproc a) where
  mempty = Postproc id
  Postproc a `mappend` Postproc b = Postproc (a . b)

The advantage I guess would be that, given a list of post-processors, you can just mconcat them together.

[cdepillabout]

Yeah, I think that sounds like a reasonable thing to do.

Especially if you'll be able to use Postproc with multiple different types, like Postproc Output or Postproc Expr.