Logging from within a Functional Programming Paradigm

Question

I prefer to stick as closely as possible to the functional paradigm, squeezing as close as I can get to the purely functional when my brain is up for the challenge. I use F# when possible. Usually, I'm stuck with either VB.NET or C# (or VBA, when I'm really unlucky). So my languages allow me to stray quite far from the functional approach.

Historically I've ignored logging and communicating with the user until I've got a result--just let the user wait. Now I'm trying to implement logging and/or updates of status bars. It's easy, because my languages allow me to write to standard output whenever I want. But from a purely functional stand-point, how does one go about leaking information about what's going on inside one's function to the outside world? Is logging or communicating with the user during computation simply contrary to the purely functional approach?

I'm sure in Haskell one would use a Monad. What about when using other languages?

Thanks.

`I prefer to stick as closely as possible to the functional paradigm, squeezing as close as I can get to the purely functional when my brain is up for the challenge` use it when it gives you some benefit. Pure functional code often may add accidental complexity to the system. — Lukasz Madon, Dec 08 '12 at 12:39

score 9 · Accepted Answer · answered Dec 08 '12 at 22:19

Let's have a look at Haskell's monadic solution. The idea behind logging is that our computations have an additional method that writes a message somewhere "out". There are many ways how to represent such computations, but one of the most general is to make a monad:

class (Monad m) => MonadWriter w m | m -> w where
    tell   :: w -> m ()

Type w represents the messages and function tell is what "sends" a message into a monadic (effect-full) computation.

Notes:

Haskell's MonadWriter is actually richer, it contains functions that allow to examine and modify w, but let's keep that aside for now.
The | m -> w part isn't really important for the explanation, it just means that w is fixed for a given m.

The most often used implementation is Writer, which is basically just a pair. One element of it is the result of a computation and the other element is a sequence of written messages. (Actually it's not really a sequence, it's more general - a monoid, which defines operations for combining multiple messages into one.) You can examine Haskell's solution by looking at the Writer module. However it's written more generally, using WriterT monad transformer, so if you're not a monad fan, it can be quite hard to read. The same thing can be done in other functional languages as well, for example see this example in Scala.

But there are other possible, more side-effect oriented (still functional) implementations of the above type class. We can define tell to emit messages to some outside sink, like to stdout, to a file, etc. For example:

{-# LANGUAGE FunctionalDependencies, TypeSynonymInstances, FlexibleInstances #-}

instance MonadWriter String IO where
    tell = putStrLn

Here we say that IO can be used as a logging facility that writes Strings into stdout. (This is just a simplified example, a full implementation would probably have a monad transformer that would add tell functionality to any IO-based monad.)

Classes and objects? Whaaaat? That's not functional programming paradigm, that's just OOP in FP. — Brian Cannard, Apr 24 '16 at 13:38
I don't see the point, type classes in Haskell are quite different from OO classes. — Petr, Apr 24 '16 at 13:42
Thank you. May be I don't see the point too. In this answer, there is no use case of the class. Please, focus on the client side of logging use instead of library. Thank you! — Brian Cannard, Apr 24 '16 at 13:44
It is interesting to see how logging type passed to functions and used to create and return logging descriptions. I mean absolutely pure part of code without any side-effects. Where the results should be aggregated together and passed to the actual logger side-effects executor? On the highest level / some intermediate level, but definitely not inside of application functions. Logging results should be only commands for a logger. It is interesting to see how one's composing such results and combines them with other functions. — Brian Cannard, Apr 24 '16 at 13:49

score 5 · Answer 2 · edited Oct 18 '19 at 06:29

I'm new to functional programming, but here's an attempt in Scala:

object FunctionalLogging {

  type Result = Int

  class ResultWithLogging(val log: List[String], val result: Result) {}

  def functionWithLogging(log: List[String], arg: String): ResultWithLogging = {
    def function(arg: String): Result = arg.length

    new ResultWithLogging(log :+ ("Calling function(" + arg +")"), function(arg))
  }

  val result = functionWithLogging(List(), "Hello world!")

  // -- Pure functional code ends here --
  println("Result = " + result.result)
  println("Log = " + result.log)
}

It's functional in that there are no side effects, but obviously the log is part of the function arguments and return, so it's not very elegant or practical.

It seems to me that logging is a desirable side-effect by definition, so if you go along with my definition the question is how to isolate the non-functional from the functional code. In practice I would probably start with a Scala object (possibly too much like a singleton - a trait is probably better Scala), or an actor to accumulate the logging messages and do whatever needs to be done with them.

This is a more pragmatic view: Logging in Scala

Edit

This question talks about Haskell Monads and IO: What other ways can state be handled in a pure functional language besides with Monads?

I like your thought process here. In my case, though, the function was rather long-running, and I wanted to report as it processed, rather than waiting for its return to report its log. Nevertheless, if no one else replies to my question, I'll probably mark this as the answer, because, while the Haskell answer is a great one, my question was more specifically about non-Monad approaches. Thanks! — Jeff Maner, Dec 11 '12 at 14:11

Logging from within a Functional Programming Paradigm

2 Answers2