Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Think on the way to make `Message` data type Semigroup #28

chshersh opened this issue Sep 14, 2018 · 1 comment


Copy link

commented Sep 14, 2018

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 chshersh changed the title Think on the way to make `Message` data type monoid Think on the way to make `Message` data type Semigroup Sep 14, 2018


This comment has been minimized.

Copy link
Member Author

commented Sep 21, 2018

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

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.