import Control.Monad.Trans (MonadTrans(..))
import Data.Foldable (toList)
import Data.Sequence ((|>), Seq, empty)

class Logger l e | l -> e where
    writeEntry :: e -> l ()

newtype Log e a = Log (Seq e -> (a, Seq e))

newtype Monad m => LogT e m a = LogT (Seq e -> m (a, Seq e))

runLog :: Log e a -> (a, [e])

runLog (Log f) =
    let (x, l) = f empty
    in (x, toList l)

runLogT :: Monad m => LogT e m a -> m (a, [e])

runLogT (LogT f) =
    do (x, l) <- f empty
       return $ (x, toList l)

instance Logger (Log e) e where
    writeEntry e =
        Log (\l -> ((), l |> e))

instance Monad m => Logger (LogT e m) e where
    writeEntry e =
        LogT (\l -> return ((), l |> e))

instance Monad (Log e) where
    Log f >>= g' =
        let fg l = let (fl, l') = f l
                       Log g = g' fl
                   in g l'
        in Log fg
    return x = Log ((,) x)

instance Monad m => Monad (LogT e m) where
    LogT f >>= g' =
        let fg l = do (fl, l') <- f l
                      let LogT g = g' fl
                      g l'
        in LogT fg
    return x = LogT (return . (,) x)

instance MonadTrans (LogT e) where
    lift x' =
        let f l = do x <- x'
                     return (x, l)
        in LogT f

liftLog :: Monad m => Log e a -> LogT e m a

liftLog (Log f) =
    let fm l = let (fl, l') = f l
               in return (fl, l')
    in LogT fm

I wonder, in what ways have I not done this well, or violated typical
conventions? I managed to get this code working, but, especially with
my use of flexible instances of Logger, I wonder if I introduced
unnecessary weirdness.

Presumably I could have instead somehow wrapped the Writer monad to do
much of this work for me while preventing users from fiddling the log.
I also wondered if it would make sense as an instance of MonadWriter.

type WLog e = Writer (Seq e)

logEntry :: e -> WLog e ()
logEntry e = tell $ singleton $ e

foo :: WLog String ()
foo = do
  logEntry "1. Entry"
  logEntry "2. Entry"
  return ()

Inside the Monad, the client really can't do a lot besides using
tell/listen/pass, and if you restrict that to logEntry, even less.

Yes, he could deconstruct the type if he really wants to, but I suppose
one could fix that with an additional newtype somewhere and hiding the
constructors, if it's really necessary.

(And if you need to give this to, say, students, don't assume they
won't find a way around it just because your hiding it...)

And especially with a function (and also with the Writer monad),
you should be very careful about strictness/lazyness, otherwise
your logging might very well happening by constructing nested thunks
instead of the actual log.

Shouldn't "encapsulation by force" be easy, though? Is the experience
you have in mind particular to Haskell-like languages? I've loved it in
languages like Modula-3, it seemed just a simple thing to want that I
figured any awkwardness would be due to deficiencies I had as a working
Haskell programmer rather than anything deeper, which is why I was
determined to try it. Perhaps my sense of this is in error. Certainly,
other things, like how instance definitions seem to have a universality
to them, don't quite fit with Modula-3-like information-hiding
intuitions.

I hadn't actually remembered that Writer works like that. (After all,
Reader doesn't feed a sequence, element by element, does it?) There's a
hint in the "Monoid w =>" in its signatures, but the Haddock
documentation is ... not very revealing, instead being the usual
reference to an academic paper that inspired the idea (and half the time
I follow those links, there seems to have been a bit of a rethink and
notation change along the way ): ). Clearly I need to do my standard
libraries refresher more often.

noteEvent newEvent actor =
    case history actor of
      Nothing -> actor
      Just oldEvents -> actor { history = Just (oldEvents Seq.|> newEvent) }

noteEvents newEvents actor =
    case history actor of
      Nothing -> actor
      Just oldEvents -> actor { history = Just (oldEvents Seq.>< Seq.fromList newEvents) }

Most of main laziness problems tend to be standard library ones, though.
For instance, the -With functions of Map. I've ended up using my own
tweaked versions of the source before to get the strictness I wanted.
Laziness creeps in where I don't want it. Even in basic things like
foldM I find myself coding, say, a variant that forces the accumulator
argument each step.

I suppose I have an innate habit of, "overengineer now, make debugging
easier later, and trust the computer more than myself".

As I said, clearly marking "normal" and "internal" operations is good
practice -- makes it easier to keep invariants, for example. Enforcing
them is bad, IMHO, because there may be situations when the client
wants more, and the programmer actually knows what he's doing.

I suppose you could also try type-constructors, something like

class Logger m where
  writeEntry :: e -> m e ()

That gets rid of the extensions.

(snip)

import M#public

to get the normal functionality, and stuff like

import M#public
import qualified M#private as MPrivate

to mess around with the internals. Which is obvious in the code because
you'd have to prefix it with MPrivate every time, so you cannot shoot
yourself into the foot without being explicit about it. Which is the whole
point.

But I don't know any language that actually does that.

If the client says "I just want to use the functions are safe and
guarantee the absence of some behaviour", fine. He should be able to
do that, and the compiler should support him in doing so. If the
client says OTOH "In this particular case, I want to use one of the
unsafe functions, and I will provide the guarantee of absence myself",
he should also be able to do that. If he can't, the penalty is more
work, up to duplication of a substantial part of the library. And
that's undesireable.

I noticed a "safe lazy IO" thing in Hackage but I haven't yet got around
to investigating it so I don't know if it addresses these concerns. I
often don't need general lazy IO, I just want to process the incoming
data in steps, forcing the result of the previous step before slurping
data for the next. I suppose I should write myself general map and fold
functions for doing that safely with strict IO.

Of course, if one's using standard convenience functions to make things
easy, then if one just puts the information into some datatype and does
a liftM read $ readFile or suchlike, it's my experience that `read'
likes to suck the whole thing in anyway, gobbling a lot of memory as it
does so, before returning. (So don't do that then. (-:)

Again: It's smart to make a distinction between a safe subset and all
the code. It's stupid to *enforce* that distinction, under all
circumstances.