[RFC] Monoidal messages with QualifiedDo

[chshersh]

This is required for extend function. Would be interesting (but difficult) think on the way how to make Message data type extensible as well.

[chshersh]

I think we can reuse typerep-map for this problem as well.
But this will be possible only after this issue is done:

• Export containers-based solution kowainik/typerep-map#53

Currently we have:

data Message = Message
    { messageSeverity :: !Severity
    , messageStack    :: !CallStack
    , messageText     :: !Text
    }

data RichMessage (m :: Type -> Type) = RichMessage
    { richMessageMsg :: !Message
    , richMessageMap :: !(FieldMap m)
    }

What I propose is to perform the following refactoring:

data Message m = Message
    { messagePure :: FieldMap Identity  -- but here should be Map from containers
    , messageRich :: FieldMap m  -- and here is still array
    }

We can construct and perform <> operation faster on FieldMap based on containers but lookup is faster for array solution. So for IO actions configured only once at the start it's better to use array solution while for pure messages it's better to use containers.

The generalisation is easy, we only need to add couple extra instances for FieldType type family. But the coolest thing that with OverloadedLabels we have generalised interface for extensible messages!

Currently we do:

log Debug "Some text..."

If we want to add extra argument to log, it will be painful breaking change. And current Message is hardcoded, it's not configurable. co-log library is not that extensible, for now it's just a basic implementation. But if we have typerep-map we can write this:

log [ #severity Debug, #msg "Some Text" ]

So it's completely extensible and users can do whatever they want with the library! But the cost is more verbose logging call. But I hope that with OverloadedLabels it's not that verbose...

[chshersh]

I finally found an acceptable solution to this problem! Since GHC 9.0 we can use QualifiedDo to have a fast and type-safe interface. The obvious monoid I was looking for is Builder. So having #93 implemented first will be a huge step forward. With QualifiedDo we can implement our custom >>= which behaves like <> but also changes type-level tags, so we can be sure that all fields are specified. Usage can look like this:

log $ Message.do
    severityB Debug
    userIdB userId

Once Structured logging is implemented, we will get messages-as-monoids for free, since in structured logging messages are key-value maps. But this QualifiedDo approach is something to keep in mind for future interface improvements.