Lane's Blog

I’ve been playing around with an Arrow concept, which to my knowledge is original. I’ve decided to call this a FactoryArrow:


newtype FactoryArrow m n a b = FactoryArrow { runFactory :: m (Kleisli n a b) }


Where m and n are Monads. m is a single-pass initialization monad, while n is a multiple-pass working monad. The arrow supports all of the standard accessory arrow typeclasses, including ArrowLoop if n implements MonadFix, and ArrowApply if m and n are the same.

This arrow simply captures a two-phase initialize-and-run design pattern.

To the best of my imagination, there cannot be a corresponding useful FactoryMonad. I would be extremely interested if anyone can contradict me on that point.

My current interest is in using the FactoryArrow as a replacement for the mealy-style arrows by using IORefs (or potentially even STM transaction variables) to store automaton states instead of unevaluated thunks.

The corresponding implementation as of the time of this writing.

Last night I checked out Scott E. Dillard’s Vec library. It’s a good, fast, pure implementation of the basic matrix operations applicable to 3D graphics. Switching to Vec has shaved off quite a bit of time from one of my demo apps and relieved me of the need to maintain my own matrix manipulation code, which was causing me repeated headaches.

It’s very heavy with MPTCs, fundeps, and type families, which will cause ghc to render some pretty inane error messages, but if you’re already accustomed to this then it’s actually very straightforward to use.