I honestly did not look too much into how Pprint works, because of its
incompatible license (as mine would be BSD rather than LGPL).
So I can’t say for sure that we have the same mechanism for linear time
printing without lazyness.
For the most part, I wanted something simple (containers.pp is less
than 500 loc), permissively licensed, and with an extension node for
styling/colors/Format-like tags (the initial use case being HTML tags
and ANSI escape sequences in the output). I also wanted to really grasp
how these Wadler-style combinators work :-).
If you’re familiar with Pprint I don’t think containers.pp brings much
to the table. But if you already use containers, it comes with it and
follows semver and all that.
Hi @c-cube
nice lib, thanks! Is there a way with Containers_pp, if I use colors (or styles), to switch them off? I tend to favor colors but also want to use some pretty printers with #install_printer, which doesn’t seem to like color escape codes.
Also, it seems like the library lacks some combinators to process arrays or iters the same way as lists or sequences.
Hi @grayswandyr ! Thanks for the kind words. There’s nothing to turn it off, but you could maybe define conditional combinators (so, decide whether to put color/style in the tree as you’re building it, not as you’re printing it). Combinators are minimalistic indeed but more would be welcome .
This is what I’m doing in my code actually.
But my reasoning was that you may have to face a situation where you only have the document already built, or you have the pretty-printer but it’s complex and it adds colors, and you can’t configure it to throw styles away, so you don’t/can’t write a second one without styles. For all this, a function akin to CCFormat.fprintf_dyn_color might have a broader impact, although the whole process is less efficient.
I’ll try to submit a PR next week if I have enough time.