Not a Voice for Me

A couple of weeks ago while searching for information on an unrelated issue, I came across an article, titled “Herding Porcupines in the MRM,” linking the Men’s Right Movement to Quakerism on the site, A Voice for Men.  Please be aware that the above link is to a site identified by the SPLC as having at least some of the characteristics of a hate group.  While I don’t care to evaluate the site in its entirety and don’t know all of the nuance of identifying what is and is not a hate group, at the time of this writing the site seems to feature an “enemies list” with names, dossiers and photographs, an advertisement (for an affiliated site) depicting blood dripping from a knife, as well as imagery and text which seem to serve no function other than to dehumanize activists from other communities.

If you’ve never encountered the men’s rights movement before, it can puzzling to newcomers.  Most people are correctly under the impression that men have rights, and many MRM groups know how to artfully incorporate legitimate concerns alongside their reactionary politics in a way that can confound outsiders.  That said, I find the movement as it is actually, widely practiced to be a manifestation of modern misogyny belonging in the same category as white supremacist and other hate-based movements.

For whatever reason the author of this particular article has chosen to identify as both a quaker, a woman, and a men’s rights activist.

That women sometimes choose to associate with the men’s rights movement is unsettling but not surprising — sexism is unique among all forms of prejudice in that it can never rely on people’s unfamiliarity with each other to perpetuate it’s vicious misconceptions.  Men and women who are exposed to misogynistic media and lack the insight to resist its influence are likely be indoctrinated with very similar ideas regardless of their gender.

I do identify as a quaker.  Although I am not a member of my meeting, I attend frequently and share many of their values.  These values, as I understand them, include taking time to listen and form consensus with every stakeholder as part of the decision-making process, opposition to all forms of violence regardless of the context in which the violence may take place, the will to defy injustice wherever it occurs, and the frequent practice of silent worship without defining the object of that worship.  I understand these values to be entirely in opposition to the values I see espoused in the men’s rights movement.

In spite of those values, it does not surprise me that a quaker somewhere in the world would identify with the men’s rights movement.  Quakers are a diverse group.  I’ve been told that some quaker meetings are almost indistinguishable from a modern conservative christian church, while others more closely resemble Occupy Wall Street organizing committees filled with youngsters eager to get themselves arrested.  The meeting I attend tends to be reserved, having taken some modest actions to contribute aid for the homeless and to agitate in favor of gay marriage.

The article itself contains little that I find objectionable because it amounts to little more than a dry review of quaker organizational structures.  I have no rebuttal to its content, but I feel that if I remain silent about this article, reasonable people might take away the idea that there exists some widespread sympathies between quakerism and the men’s rights movement.  I find this possibility utterly horrifying.  A Voice for Men and sites like it do not speak for me or my meeting.  I have no doubt that the ideas advocated by the men’s rights movement would be greeted by strenuous protest among the overwhelming majority of friends at my meeting, several of whom are feminists.

My only real goal in posting this is to provide some guidance to anyone who may have come across this article and be curious as to whether it represents a presence of men’s rights sentiments in modern quakerism.  I believe that it does not.

ANN: Roguestar

Roguestar is now up on hackage.  You can install and run with:

$ cabal install roguestar roguestar-glut roguestar-engine
& ~/.cabal/bin/roguestar

The latest version brings:

  • New monsters: Hellions and Dust Vortexes
  • Underground dungeons
  • Power-ups (hidden in the aforementioned dungeons) that serve to level-up the player’s character.
  • Improved walking animation.
  • It’s no longer possible to spawn with zero sight range.
  • Fixed some of the worst of the user interface glitches.

Under the hood, I’ve also split RSAGL into a few topic-specific libraries and implemented value recursion in rsagl-frp.  There is an experimental GTK-based client, but I don’t recommend it just yet, which is why it isn’t on hackage.

I’ve also migrated the project to github, which includes source code, the manual, and the issue tracker.

The One Function per Typeclass Rule

After about five years programming in Haskell, I think we need a rule:  Only put one function in a typeclass.

Why?  Because inevitably someone comes along with a data type for which one or the other function of a typeclass is perfectly suited, and yet another function of the same typeclass is not implementable.

Here are some examples of consequences of breaking the rule:

  1. The Infamous Set Monad, which requires splitting Monad in half. (Monad)
  2. All of the abstract ways to construct Nothing: fail (Monad), mempty (Monoid), mzero (MonadPlus), empty (Alternative).  Not surprisingly, all of these typeclasses are subtly related.
  3. The natural numbers, which have a minBound, but not a maxBound (Bounded) . . .
  4. . . . and which support addition and multiplication, but aren’t closed under subtraction and for which the concept of a sign does not exist (Num).
  5. My own memoizable message type, which would like to implement Applicative, but needs a monadic computation to implement pure. (Applicative)

It’s a little extra typing to write multiple “class . . . where” clauses for each type that needs to implement a large number of type-indexed functions, but it’s quite easy to combine related typeclasses when appropriate, as follows:

class Foo a where
    foo :: a -> b

class Bar a where
    bar :: a -> b

class (Foo a,Bar a) => FooBar a where
    {this space intentionally left blank}

In conclusion, you should definitely follow this rule if I have convinced you that it is a good idea to follow it.

But does it crawl?

Roguestar is officially a dungeon crawl now, as it actually has dungeons:

An Androsynth visits the dungeon.
An Androsynth visits the dungeon.

For the moment I’m ok with the empty black pits, but I want to do something with the skylights.  Maybe slant them at an angle?  I’ll probably also change the dungeon lighting to some kind of red-orange shining up with the camera light at half-brightness.

I have a lot less free time now than I used to, so I’m trying to focus on specific game features and spend less time fiddling with stuff (like FRP semantics) under the hood.

Memoized Dataflow Streams

In reactive programming we can choose between two models: “pull,” in which we run a computation each time output is required, and “push,” in which we run the computation each time input arrives.

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.
Diagram demonstrating memoized message passing semantics.
Memoized Message Passing Semantics

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

ANN: Roguestar-

Roguestar is a science fiction roguelike game written using Haskell and OpenGL.  It is in the early stages of development.  At this time, it is not a winnable game.

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

– or –

$ git clone
$ cd roguestar
$ git checkout
$ 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

Check it out!

A Brutal Introduction to Arrows

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