Which model we use depends on whether we are working with high-frequency or low-frequency data.  If we are writing a piece of avionics software that measures pitch, yaw, and roll, then we need to constantly adjust the plane’s aerodynamic surfaces based on those variables.  We don’t need a notification when these variables change, because they change constantly.  The pull model would be perfect in this case.

On the other hand, engine temperature is every bit as critical to the health of the vehicle, but presumably that variable remains in equilibrium for long stretches of time, and small variations aren’t important.  We don’t want to waste CPU time monitoring temperature 100 cycles per second.  We might simply want to receive a notification whenever the engine temperature changes by 1 degree or more.  The push model works better here.

The problem:  How do I efficiently embed a low-frequency signal in a high-frequency channel?  If I pass the low-frequency signal naively, it will work, but entail much redundant computation.

When we want to avoid recomputing a value, we often use a memoization strategy.  However, in this case we need to memoize a data stream, not a function.

In the engine temperature example, it would be easy to memoize a function of type Int -> a.  But we want to compose this function as part of a signal.  After all, if the engine temperature is low frequency, then so is any signal derived from the engine temperature.  The chain of transformations should be memoized along its entire length.  Further, this function risks artificially escalating a meaningless low-amplitude high-frequency component of an otherwise low frequency signal by imposing an arbitrary boundary: suppose that some engine vibration causes the temperature to oscillate rapidly between 198.9 and 199.05 degrees, which would truncate to 198 and 199?  This does not yield the notification heuristic we are looking for.

The solution:  Tag information with a unique signature at its point of departure and then memoize it at the point of arrival. Transformations of the data stream also need to be tagged.  A source signature is either a unique integer, or an annotation of applying one signature to another. There is some overhead associated with comparing signatures, but this overhead can not be greater than the cost of performing the underlying operations.

Memoizable messages are very similar to applicative functors.  They can not, however, implement the Control.Applicative interface, because any pure constructor would be unsigned and therefore destroy memoization.

This memoization scheme requires three operations:

• Transmit: Sign a message with a unique signature, indicating its source.  If a subsequent signal is sufficiently similar, reuse the same signature.
• Receive: Unpack a signal, memoizing against the signature of the previous input.
• Apply: Combine two signals with their signatures.

Memoized Message Passing Semantics

My implementation is in a module of rsagl-frp called Message.hs.

$ cabal install roguestar-engine
$ cabal install roguestar-gl
$ ~/.cabal/bin/roguestar

- or -

$ git clone http://www.downstairspeople.org/git/roguestar.git
$ cd roguestar
$ git checkout 0.4.0.1
$ make install

New gameplay features:

• Melee combat, sundering and disarming attacks
• Weapons can sometimes overheat or explode
• Gateway teleportation between planets
• Use material-spheres to craft new tools
• Use material-spheres to heal
• Tab-completion of typed commands
• Compass directions to significant artifacts
• “Jump” short distances by teleporting

New objects:

• Chromalite material spheres
• Metallic material spheres
• Gaseous material spheres
• Energy sabres and fleurets
• Gateways
• Monoliths

New graphics features:

• Randomly generated sky spheres and landscapes
• Unique fractal trees
• Zoom-in/zoom-out

Changes under the hood:

• Major re-write of the RSAGL FRP architecture
• Multi-threaded 3D scene assembly and rendering
• Multi-threaded, anticipatory engine
• Various OpenGL performance improvements

For more information, links to the manual and git repository, visit http://roguestar.downstairspeople.org.

Check it out!

Imagine being killed by a bow and arrow. That would suck, an arrow killed you? They would never solve the crime. "Look at that dead guy. Let’s go that way." — Mitch Hedberg

I seem to be one of the few people who absolutely adores arrows. I thought it might be helpful if I provided some insight to the advanced-level newbies regarding the practical use of arrows in Haskell. Plenty has already been written about what arrows are in category theory, how to implement the Arrow typeclass, and how to use the special arrow syntax. I want to talk about why I occasionally wake up in the morning thinking, "Maybe I could solve this problem using arrows!"

This article is just to share an extremely simple, intuitive and concrete example of an arrow. I’m not going to get into all the crazy amazing things arrows can do. I just want to show that they can do at least one cool useful thing.

Arrows are closely related to monads. For example, both arrows and monads can be used to capture side-effecting operations.

Monads have the kind * -> *, indicating a side-effecting operation with a single output type, and a binding operation m a -> (a -> m b) -> m b. The input to a monadic operation is provided via a pure function. Arrows, on the other hand, have a kind * -> * -> *, indicating a side-effecting operation with a single input type and a single output type, and a binding operation a b c -> a c d -> a b d.

When binding monads, it’s obvious from the type signature that the subsequent side-effecting operation does not even exist until after the output of the previous operation becomes available. It cannot, because it depends on the previous output and because we can inject any pure function to construct the subsequent operation based on completely arbitrary criteria.

When binding arrows, the subsequent side-effecting operation exists before execution begins.

All monads are arrows, but not all arrows are monads, and this observation is pertinent to their implementation in Haskell, but I’m going to restrict this article’s discussion to "interesting arrows," specifically, arrows that aren’t monads because they don’t implement ArrowApply. Interesting arrows are basically monads without flow control: you can’t generally choose what side-effecting actions to perform based on things you learn during the execution of the arrow.

This is why arrow-notation creates two scopes. Between the <- -< symbols, only values that were in scope before execution of the Arrow are in scope. Outside the <- -<, values that appear during the execution of the Arrow are also in scope.

For example, we (you and I) might have a monad that allows us to perform certain dangerous operations, like overwriting files. In a monadic context, we can not anticipate what any particular instance of the monad will choose to do. We might write a very complicated installation script that accesses many files. Do we have permission to write to all of those files? Do the files we want to read even exist? Do we access an infinite number of files?

Do we ever write to /dev/nuclear_missiles?

We would like to know the answers to these questions before running the installation script, otherwise we could be interrupted and leave the system in a chaotic state. Even if we could recover from an error, we would still be wasting the user’s time, which is the opposite of the thing that computers are for.

But if we implemented our IO environment using an arrow, we could anticipate all of the side-effecting operations, even have a list of files to be overwritten before the operation begins.

In our new file IO arrow, it will be impossible to read the name of a file from a file, and then write to that file dynamically, because all file names must be specified at the time the arrow is bound. That’s a pretty onerous restriction, but we can always add new operations later, if we need them.

Our arrow needs a list of accessed files and an IO action. The list of file paths is going to take the form of a monoid, while the sequence of IO actions will take the form of a Kleisli arrow.

data IORWA a b = IORWA [FilePath] (a -> IO b)

We need a category instance.

instance Category IORWA where

Implementing id is easy. Id accesses no files, so we give an empty file list. Return is the simplest monadic action that type checks.

id = IORWA [] return

The bind operation requires that we concatenate two lists of file paths, and bind the IO actions. (This is a little annoying, but note that the (.) operator specifies the preceding action second and the subsequent action first.)

(IORWA sa actionA) . (IORWA sb actionB) = IORWA (sa ++ sb) (\x -> actionB x >>= actionA)

At this point, we only have a category, which has only slightly more sophistication than a monoid. To get our tricky arrow syntax, we need to implement arr and first.

instance Arrow IORWA where

Arr, like id, doesn’t touch any files, so we provide an empty file list and inject the function into the arrow.

arr f = IORWA [] $ return . f

First is a little tricky. We’re accepting a side-effecting operation as a parameter, so we need to preserve that operation’s file list.

first (IORWA s action) = IORWA s $ \(x,k) -> do { x' <- action x; return (x',k) }

And we need read/write operations, in which we simply pack the file path parameter into the file list. Notice that we take the file path as a static parameter, but we take the data to write as an input to the arrow.

writeFileA :: FilePath -> IORWA String ()

writeFileA path = IORWA [path] $ \s -> writeFile path s

readFileA :: FilePath -> IORWA () String

readFileA path = IORWA [path] $ \_ -> readFile path

Using our arrow is as simple as exporting a function to the accessed file list and the IO action, as long as we refuse to export any way to corrupt the synchronization between the two fields.

Looking at Control.Arrow and the arrows library on hackage, there are a few things we could add to all this:

• We could implement ArrowChoice. This would allow us to choose at runtime between accessing two different sets of files. Both possibilities would appear in our static accessible file list, but only one would actually be accessed.
• We could use a modified ReaderArrow to capture rewriting rules for file paths, e.g., to specify a current working directory. We can’t use ReaderArrow directly, because it would route information through the monadic component of the computation.
• We could use a WriterArrow to retain a log of all of the data we actually write.
• We could use an ErrorArrow to recover from file system errors.
• We could implement ArrowLoop based on the MonadFix instance of IO.
• We could use the Automaton arrow to implement multi-phase read/write cycles. Perhaps the first phase would be read-only, then we could check the file list again before proceeding to the second phase.
• We could re-implement what we just wrote in terms of the StaticArrow and Kleisli arrows, and get a metric ton of the above for free.

To play with this example, you could always git clone http://www.downstairspeople.org/git/IORWA.git.

Blocking-transactions is an alternative library that implements atomic transactions using locks. This library is strictly less expressive than STM, but does have some advantages.

First, I will demonstrate why such a library is even possible. In order to implement a blocking transaction, we must:

1. Sort all of the variables that could participate in the transaction.
2. Sieze a lock on each variable in sorted order.
3. Perform the transaction.
4. Release all of the locks.
5. Notify any waiting threads that the variables have been modified.

Acquiring locks in sorted order guarantees that the program can not deadlock. Acquiring a lock effectively acquires the exclusive right to acquire any greater-ordered locks before any thread that has acquired a lesser-ordered lock.

None of this is possible unless we know the entire set of variables before the transaction takes place. In traditional models of computation, this is impossible. However, arrows provide an environment of restricted flow control in which all computations are either inevitable or in which there is a finite set of branches. The StaticArrow is an example of an Arrow that can do this.

It is also possible to build a monad with similarly restricted flow control. If the side-effectful operations of a monad always return an opaque value (meaning that there is no function that can transform the value or any combination of values into a boolean) then no flow control within the monad is possible.

Such a library has a profound limitation: although we can store a transactional variable inside another transactional variable, we can not retrieve it without considerable contortions. Blocking transactions therefore do not seem to be suitable for working with complex graphs of transactional variables.

On the other hand, the restricted flow control that blocking transactions require presents an unexpected opportunity: transactions can be made inevitably lazy. A lazy transaction completes in the time it takes to entangle the variables in a system of unevaluated thunks. This means that the locks are held for the shortest time possible, but increases the CPU time needed to complete the entire program.

These systems of unevaluated thunks constitute a potentially hazardous memory leak. I choose to write the library in such a way that each variable is forced after the transaction completes, by means of a parallel spark.

This is not the only strategy for evaluating a transaction. We could also choose to:

• Allow values to be forced within the transaction, but locks could be held while an expensive and unimportant computation completes. We would then want a strategy to release unneeded locks early, but this would add overhead.
• Sequentially force each variable after the transaction, but this was not efficient in the benchmark.
• Specify a per-variable strategy for forcing each variable, but this is adds complexity with little apparent benefit.
• Tolerate the memory leak on the assumption that the caller must manually force the contents of the transaction, but this had catastrophic implications for performance in the benchmark.

Note that the blocking transactions library at the moment is not exception safe.

My implementation is available as a git repository. You can also link directly to the source code and a simple benchmark.

$ git clone http://www.downstairspeople.org/git/blocking-transactions.git/

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.