Made MSF and PureGameEnv newtypes.

[Icelandjack]

I wanted to test different monoid instances for MSF, I tried Ap but only the first one worked because MSF is defined as a data not a newtype. Making it a newtype means coerce and deriving works fully

deriving
  via MSF m a `Ap` b
  instance (Monad m, Semigroup b) => Semigroup (MSF m a b)
deriving
  via MSF m a `Ap` b
  instance (Monad m, Monoid b) => Monoid (MSF m a b)

vs

-- FAILS: MSF f a b is not represented as a function in memory
deriving
  via a -> Ap f (b, MSF f a b)
  instance (Applicative f, Semigroup b) => Semigroup (MSF f a b)
deriving
  via a -> Ap f (b, MSF f a b)
  instance (Applicative f, Monoid b) => Monoid (MSF f a b)

[freckletonj]

Is it just an oversight that MSF wasn't newtyped originally? I'd expect this PR to be an easy speedup without any costs.

[walseb]

There are pros and cons I believe: #169

[freckletonj]

ah, it eliminates one level of laziness. Interesting point.

[ivanperez-keera]

Indeed, the choice of not making MSF a newtype was deliberate. Thanks for pointing to that issue, @walseb .

I'd love to be able to answer these questions with data that shows whether it's better or worse. We've found many cases in FRP implementations where "obvious" optimizations introduce a penalty only larger examples or with newer GHC releases, so I'm always on the edge about performance improvements when I don't have the data to back up the decision.

We've had an open issue for some time of doing good data-driven, no-interaction-needed benchmarks on MSFs. It's not a research problem. It's an engineering problem. If we had that, we'd have a much better way of making decisions about code optimizations.

Additionally, and based on some experiments I did (with Martin Handley), a lot of Yampa has been optimized but is actually no faster than plain straightforward Haskell because GHC has changed so much. That opens the opportunity of reducing the Yampa codebase, and making it more abstract. The smaller that Yampa becomes, the more we can just put on top of dunai without any performance penalties. They would both become easier to maintain and more versatile.

I don't want to block the development of dunai, but, of course, my eyes are on the goal of data-driven benchmarks because it would just allow so much progress to be made.

[ivanperez-keera]

Also relevant: #233