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.

Posted in Haskell | 2 Comments

Vec is Good

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.

Posted in Haskell | 1 Comment

ANN: priority-sync

Provides cooperative task prioritization.

The priority-sync package on hackage.haskell.org.

$ cabal install priority-sync

$ git clone http://www.downstairspeople.org/git/priority-sync.git

Feedback will be greatly appreciated. This package is a spin-off from my work on roguestar, where I need to do significant background processing while retaining enough resources to perform smooth animation.

Posted in Uncategorized | Leave a comment

Trends in Profiling Haskell

I spent some time yesterday profiling roguestar. I do this every few months just to see where things stand, and there are always two culprits at the top of roguestar-gl.prof, every single time:

* typeclass dictionary lookups in inner loops
* Rational

In the first case, I think the simplest solution is to INLINE the puppy. Can the ghc inliner be a little bit more aggressive when it sees dictionary lookups? Inliners are tricky business. I’m not sure I see a simple heuristic. Vaguely: leaf functions that require dictionary lookups need to be specialized.

Rational can sneak into an unsuspecting program through realToFrac, and absolutely *kills* performance.

I sit down thinking to myself, “Ok, today I’m going to streamline my Super Mumbo Jumbo Widget and get 15% faster performance,” or some such goal I set for myself. And I run the profiler and 75% of my time is being spent in fromRational . toRational.

Posted in Haskell | 5 Comments

Twilight Hero

Hero fights off recreant using the new melee rule mechanics for roguestar.

Here we see our hero fighting a recreant with a kinetic sabre. The material spheres front and left can be used to repair yourself, while a phase rifle is to the right. In unskilled hands, such powerful weapons can more dangerous to the user than enemy.

Posted in Roguestar | Leave a comment


As I’ve found myself repeatedly writing a bit of code that looked vaguely like this:

get :: SomeArrow String (Maybe Thing)

foo :: [Thing] -> FooThing

. . .

getAToZ :: SomeArrow () (Maybe FooThing)
getAToZ = proc () ->
    do m_a <- get -< "a"
       m_b <- get -< "b"
       . . .
       m_z <- get -< "z"
       returnA -<
           do a <- m_a
              b <- m_b
              . . .
              z <- m_z
              return $ foo [a,b . . . z]

It seemed that there would have to be a way to automate this. So I wrote this MaybeArrow (careful, I’m still using 6.8.2 so it’s the old arrows with ‘pure’.). I know that there is already an ErrorArrow. But ErrorArrow as far as I can see requires ArrowChoice, and I’m not doing that. In the MaybeArrow, if an earlier computation throws a Nothing, then later computations are still allowed to perform side effects, although their outputs are snuffed, which is the behavior I want.

I would appreciate any constructive feedback.

If you’re wondering the use case has to do with waiting on several separate pieces of information to arrive from a server and combining them into one output message.

Posted in Haskell | 10 Comments

A New Dawn?

This is what I imagine a very cold (~2000K) red star might look like at sunrise. I’m not sure if it matters whether it is a red giant or red dwarf — the system tries to size the star semi-realistically according to the temperature of the star and the climate of the local planet, so it should have about the same apparent size either way. A blue star would always look very small, even though these stars are always giants, because if you were ever close enough that it looked big, it would just sterilize you.

The mysterious green object in the upper right corner is a cyborg planet killer. It’s really big and powerful, so don’t **** it off.

Red Giant Sunrise

In other news, for my United Statesian readers, it’s election day! All you have to do is show up, wait in line a little while, and draw a little line to the right arrowhead, or pull a lever or however it’s done in your state. Try not to **** it up. Unless you have electronic voting machines, in which case the cyborgs will take care of it, so don’t bother.

If you have astrophysics brains and don’t mind feeding them to my zombie code monkey, maybe I can make more realistic stars?

Posted in Roguestar | Leave a comment