dunai
dunai copied to clipboard
Made MSF and PureGameEnv newtypes.
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)
Is it just an oversight that MSF
wasn't newtype
d originally? I'd expect this PR to be an easy speedup without any costs.
There are pros and cons I believe: https://github.com/ivanperez-keera/dunai/pull/169
ah, it eliminates one level of laziness. Interesting point.
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.
Also relevant: https://github.com/ivanperez-keera/dunai/issues/233