How would I implement “best-effort” pretty rendering in roc? · beginners

Stream: beginners

Topic: How would I implement “best-effort” pretty rendering in roc?

Lukas Juhrich (Jan 25 2026 at 13:41):

Hi,

I may well have some basic misunderstandings about roc's abilities and design philosophy, but let me elaborate.

I've been thinking how one would build colorful pretty-printing like the rich library in python provides, which has become the de-facto standard for nice human readable output. It features reasonable defaults but its behavior can also be extended for user-defined types.

As far as I undrestand, pprint renders some piece of data like this:

If it has a __rich_repr__() method, use its value to build up the repr
otherwise, fall back to a reasonable default defined for e.g. lists, dictionaries or dataclasses (which would be records in roc)

roc does not have python's dynamic introspection, so I figured I had to choose between this:

build a giant function which switches based on the argument type, and continue to add special cases. but since there is neither ad-hoc polymorphism nor an „any“ type, this can't be done.
try to associate a function rich_repr to existing types. Since, in contrast to e.g. rust, we cannot associate functions to a type outside the original type definition, we'd need a wrapper type, say Rich, providing rich_repr(). But then we essentially just moved the problem: how do we define a to_rich function which, depending on the type, returns a different instance of Richcontaining the information about how to format?

Is roc missing some kind of overloading (rust's „trait X can be implemented from various sources“ compile-time-lookup of what a method may mean would also count as overloading in a broad sense), or am I just lacking a smart idea?

(edit: I'm talking about the new compiler, and specifically not about “abilities”)

Dan G Knutson (Jan 25 2026 at 14:06):

I think you could implement this kind of pretty-printing in terms of 'encode', at least in the fully built-out version of encode that's planned. If you did it this way, 'RichRepr' would be an encoding format (kind of fitting into the same slot as 'json' or 'cbor').
Brendan also said that a pattern like this was how dbg statements and the associated Inspect module was implemented in the old rust compiler.
#ideas > Encode/Decode and reflection use-cases

Lukas Juhrich (Jan 25 2026 at 14:09):

I haven't come around to a full understanding of encode yet, so I will take this opportunity to think about it more deeply. Thank you for the pointer!

Last updated: Feb 20 2026 at 12:27 UTC