Are MonadLogger and MonadLog instances necessary?

[NicolasT]

Integrating MonadLogger or MonadLog sounds a bit too opinionated, is this necessary?

Raised by @TristanCacqueray in https://discourse.haskell.org/t/towards-an-actor-framework-for-haskell/5929/10, based on the content of https://github.com/NicolasT/troupe/wiki/Design-Ideas/.

[NicolasT]

I agree this is opinionated. At the same time, I believe it makes sense 😃 Allow me to explain.

Like Erlang, I imagine this project to be used in server-style applications, i.e., handling requests with some IO effects. In production (and even development), logging is important, and should be encouraged/made easy.

Whilst of course it'd be possible to push providing the ability to log from process code towards the library consumer, I don't think it's that simple. Since ProcessM isn't (and IMHO, should definitely not be) a transformer, one could define type MyAppM a = LoggingT ProcessM a, then write something like runMyApp l a = runProcess (runLoggingT l a) (from memory), and mySpawn p = getLogger >>= \l -> runMyApp l p.

However, how would this work when other code, e.g., a supervisor, needs to spawn a new process? One could argue a supervisor should somehow take a spawn action as an argument, and use that. Indeed, then a supervisor could work for MyAppM instead of only for ProcessM. However, I'm not convinced that results in a user-friendly API.

In the end, if runRootProcess takes some logger as an argument in order to fulfill the MonadLog(ger) needs, one can pass in a logger which drops every message (if any) on the floor.

[TristanCacqueray]

That makes sense. I was wondering if the logger could also be an actor, for example to handle forwarding the event to a remote system. Or perhaps this should be a separate system.

[NicolasT]

Oh, for sure, as is the case in Erlang. MonadLog{ger} are basically ReaderTs with some callback for log messages as the value. Such callback could indeed send log messages to some logger process for further handling.

[dpwiz]

I'm afraid (or, rather, hope 😄) that some systems would want structured logging - emitting JSON/CBOR/etc documents instead of plain text. And different systems would have different requirements. The logging system thus would be peppered with format type parameters or something else to burden its users.
Add different attributes like priorities and (oh woe) security tags, glaze with endpoint routing and it would be a mess real quick.
Having a plug-n-play "text-to-handle" process would be nice, but it should be marked clearly that it is a stub and you really ought to think about your logging/tracing/auditing pipeline.

[dpwiz]

Of course, having the thing may realistically dwarf the scope of the base package. I just want to avoid locally optimal "success" which would set users up for a fail by being easily accessible, even if problematic in long-term.

[NicolasT]

Would you have an idea on how to make logging work generically (over log "framework")? Say, this logging library defines some MonadLog class with a logSomething :: LogMessage -> m () action.

Assuming we can implement logSomething with some info from a ReaderT-like context, we can provide an orphan instance of MonadLog for ProcessM r a somewhere (from memory):

class HasDoLog r where
  doLog :: r -> (LogMessage -> IO ())

instance HasDoLog r => MonadLog (ProcessM r) where
  logSomething msg = asks doLog >>= \dl -> liftIO (doLog msg)

Then, one can do something like

instance HasDoLog MyEnv where ...

spawnSomeProcess :: ProcessM MyEnv ()
spawnSomeProcess = do
  dl <- asks doLog
  spawn {- :: ProcessM MyEnv ProcessId -} $
    runWithLogging dl {- :: (LogMessage -> IO ()) -> LoggingT m a -> m a -} $
      do ... {- :: LoggingT (ProcessM MyEnv) a -}

Fine. Now here's a problem: this works when the user of the library spawns new processes, and can hence inject some logging layer inside the ProcessM. However, there'll be a lot of code which spawns processes, where the user can't necessarily wrap things. E.g., a supervisor will (re)spawn processes "internally".

I somehow have the feeling I'm missing something obvious and there's no problem at all, but at the same time, I fail to see how we can make this work without handling this inside this libary (and hence, not work out-of-the-box by non-supported logging frameworks).

[TaylorEwtonQ]

In general, logging is important in server-style applications that handle requests with IO effects. It is often useful to provide the ability to log from process code to make logging easy and encouraged. While it is possible to push the responsibility of providing the ability to log towards the library consumer, it may not always be simple.

[dpwiz]

If ProcessM has that env parameter to share common set of handles across spawned actors then its is a matter of having a constraint for the desired log implementation.

For the generic process that want to do text/line-oriented logging... There is a problem that some actors elsewhere may need to do structured logging instead. So there should be a merge point to intercept messages from different sources and format them appropriately for the system. 🤔

[k-solutions]

I think the approach to keep the ProcessM as simple as possible and let programmers decorate it with additional features is aligned with Erlang philosophy . As long as we could ensure zero-cost or near zero-cost message passing ac cross process, we could have something useful to extend upon.