Freer Monads: Too Fast, Too Free :: Reasonably Polymorphic
CRANK

The venerable Lyxia had this to say about my last post on freer monads:I agree the performance argument is way less important than the frequency at which it's thrown around makes it seem. The reason freer performance sucks is that you're repeatedly constructing and deconstructing trees at runtime. However, that is only a consequence of the implementation of freer as a GADT (initial encoding). I bet the final encoding can do wonders:newtype Freer f a = Freer (forall m. Monad m => (forall t. f t -> m t) -> m a)I spent a few days working through the implications of this, and it turns out to be a particularly compelling insight. Behold the microbenchmarks between freer-simple and an equivalent program written against mtl:benchmarking freer-simple time 745.6 μs (741.9 μs .. 749.4 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 745.1 μs (742.2 μs .. 748.5 μs) std dev 10.68 μs (8.167 μs .. 14.23 μs) benchmarking mtl …

reasonablypolymorphic.com
Related Topics: Functional Programming Marketing