dunai icon indicating copy to clipboard operation
dunai copied to clipboard

Made MSF and PureGameEnv newtypes.

Open Icelandjack opened this issue 4 years ago • 5 comments

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)

Icelandjack avatar May 14 '20 07:05 Icelandjack

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

freckletonj avatar Aug 21 '21 00:08 freckletonj

There are pros and cons I believe: https://github.com/ivanperez-keera/dunai/pull/169

walseb avatar Aug 21 '21 01:08 walseb

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

freckletonj avatar Aug 23 '21 18:08 freckletonj

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 avatar Aug 31 '21 12:08 ivanperez-keera

Also relevant: https://github.com/ivanperez-keera/dunai/issues/233

ivanperez-keera avatar Aug 31 '21 12:08 ivanperez-keera