This is a bit of a tangent, but one can use the FoldM http://hackage.haskell.org/package/foldl-1.2.1/docs/Control-Foldl.html#v:Fol... type from the foldl http://hackage.haskell.org/package/foldlpackage to build composable logger-like things that perform effects. The semigroupoids package contains the Extend http://hackage.haskell.org/package/semigroupoids-5.0.1/docs/Data-Functor-Ext... typeclass, which is basically "Comonad without extract". If we make FoldM an instance of Extend, we can "single-step" a FoldM with the function: import Data.Functor.Extend (duplicated http://hackage.haskell.org/package/semigroupoids-5.0.1/docs/Data-Functor-Ext... ) import qualified Control.Foldl as L singleStep :: i -> L.FoldM IO i r -> IO (L.FoldM IO i r) singleStep i :: flip L.foldM [i] . duplicated Which is basically a logging function. Also, since FoldM is an instance of Applicative, you can combine a list of loggers using sequenceA_ http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-Foldable.html#v:se... . Another way to define a logger type would be with Cofree http://hackage.haskell.org/package/free-4.12.4/docs/Control-Comonad-Cofree.h...from the free package. Something like: type Logger = Cofree ((->) String) (IO ()) Which would also be an Applicative. One could then define stateful loggers using Cofree's unfold <http://One then could define loggers using unfold.>. I think the Cofree version has the advantage that you can be sure the logger's state only depends on the messages it receives (even as it emits IO actions on each step). The FoldM version, meanwhile, could perform some devious IO action to update its state. On Saturday, June 4, 2016 at 3:24:57 PM UTC+2, martin wrote:
Hello all,
I find myself frequentlly writing types like this
data Logger a l = Lgr { runLogger :: a -> Log l -> (Log l, Logger a l) }
The purpose is to give a logger a chance to carry an internal state. It could e.g. choose to log only every n invocations. To do this it must keep track of how many times it has been called. I want to leave such things private to the Logger.
(1) I know that this is not an unusal thing to do, but it has an OO feel to it. Is there a more functional alternative to it. Should I just not worry?
(2) I can write a combinator which creates a Logger from a list of Loggers. Since each Logger potentially returns a new version of itself, I must always re-assemble the combined logger from all the returned new versions. I am worried that this is a costly operation, particularly when most Loggers just return themselves unaltered. I don't have any hard numbers about the performance penalty though.
These Loggers are used in a discrete-event-simulation and they will get called many times (once for each event), but only occastionally actually write to the Log. _______________________________________________ Haskell-Cafe mailing list Haskel...@haskell.org javascript: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe