I’m thinking of something like (rough ECMA-like pseudocode):

static var clicks = 0;

drawRectangle( 0, 0, 100, 100)
drawText( 0, 50, "This button has been clicked " + clicks + " times" )
drawClickListener( 0, 0, 100, 100, function() { clicks++ } )

Now we should be able to wrap this “button” inside affine transformations and clipping operations. We would call and draw the button during each frame of animation, and the button would cease to exist on the first frame in which it stopped being called.

I’m not looking for a revolutionary GUI paradigm; I just want the ability to do some specific, weird effects when the situation calls for it. For example, a car driving by with a clickable button on it’s side. If the button is behind a tree in the same scene, then it shouldn’t be click-able.

In fact, ideally, drawing user interface elements would use the same path as drawing visible shapes, but would pass in an event handler instead of a color or fill pattern. I could even imagine that there would be one or more channels of callback information alongside the RGB channels.

This is in the category of “things that I can’t possibly be the first person to think of but haven’t actually ever seen done.”

An Androsynth standing in front of a stargate.

When you are done on a planet, step through a gateway to move to the next one.


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.

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.

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.

* 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.

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.

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.

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.

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?

This is actually very low resolution. It uses a simple media ray tracer that can handle some common atmosphere models. The tracer runs in a background thread and the result is just pasted onto a sky sphere.

More shots as I refine the lighting.