After several refactorings monadic stack for logging will be scary:
ReaderT for LoggerName
ReaderT for LogInternalState for IO-logger.
ReaderT for LoggerConfig.
Having three nested ReaderT for representing just single effect looks ugly to me... Also, it's worse for performance rather than having single ReaderT. Though, abstraction through effects is necessary to support pure logging. Having two separate type classes probably not necessary:
HasLoggerName for taking logger name from context
CanLog for dispatching logger names.
Proposal
Merge HasLoggerName and CanLog into single type class.
Have two ReaderT-like data types: for pure and non-pure logging.
Abstract LoggerConfig in some way that it can be specified partially. Also it should store LoggerName for current logger as well.
chshersh
commented
6 years ago
After several refactorings monadic stack for logging will be scary:
ReaderTforLoggerNameReaderTforLogInternalStateforIO-logger.ReaderTforLoggerConfig.Having three nested
ReaderTfor representing just single effect looks ugly to me... Also, it's worse for performance rather than having singleReaderT. Though, abstraction through effects is necessary to support pure logging. Having two separate type classes probably not necessary:HasLoggerNamefor taking logger name from contextCanLogfor dispatching logger names.Proposal
HasLoggerNameandCanLoginto single type class.ReaderT-like data types: for pure and non-pure logging.LoggerConfigin some way that it can be specified partially. Also it should storeLoggerNamefor current logger as well.