### Seminearrings

5/2/14 22:17**winterkoninkje**

So there was a discussion recently on the libraries mailing list about how to deal with `MonadPlus`

. In particular, the following purported law fails all over the place: `x >> mzero = mzero`

. The reason it fails is that we are essentially assuming that any "effects" that `x`

has can be undone once we realize the whole computation is supposed to "fail". Indeed this rule is too strong to make sense for our general notion that `MonadPlus`

provides a notion of choice or addition. I propose that the correct notion that `MonadPlus`

should capture is that of a ** right-seminearring**. (The name right-nearsemiring is also used in the literature.) Below I explain what the heck a (right-)seminearring is.

### Monoids

First, I will assume you know what a monoid is. In particular, it's any *associative* binary operation with a distinguished element which serves as both *left- and right-identity* for the binary operation. These are ubiquitous and have become fairly well-known in the Haskell community of late. A prime example is `(+,0)`

—that is, addition together with the zero element; for just about any any notion of "numbers". Another prime example is `(*,1)`

— multiplication together with unit; again, for just about any notion of "numbers".

An important caveat regarding intuitions is that: both "addition" and "multiplication" of our usual notions of numbers turn out to be *commutative* monoids. For the non-commutative case, let's turn to regular expressions (regexes). First we have the notion of regex catenation, which captures the notion of sequencing: first we match one regex and then another; let's write this as `(*,1)`

where here we take `1`

to mean the regex which matches only the empty string. This catenation of strings is very different from multiplication of numbers because we can't swap things around. The regex `a*b`

will first match `a`

and *then* match `b`

; whereas the regex `b*a`

will match `b`

first. Nevertheless, catenation (of strings/sequences/regexes/graphs/...) together with the empty element still forms a monoid because catenation is associative and catenating the empty element does nothing, no matter which side you catenate on.

Importantly, the non-deterministic choice for regexes also forms a monoid: `(+,0)`

where we take `0`

to be the absurd element. Notably, the *empty* element (e.g., the singleton set of strings, containing only the empty string) is distinct from the *absurd* element (e.g., the empty set of strings). We often spell `1`

as `ε`

and spell `0`

as `∅`

; but I'm going to stick with the arithmetical notation of `1`

and `0`

.

### Seminearrings

Okay, so what the heck is a right-seminearring? **First,** we assume some ambient set of elements. They could be "numbers" or "strings" or "graphs" or whatever; but we'll just call them elements. **Second,** we assume we have a semigroup `(*)`

— that is, our `*`

operator is associative, and that's it. Semigroups are just monoids without the identity element. In our particular case, we're going to assume that `*`

is *non-commutative*. Thus, it's going to work like catenation— except we don't necessarily have an empty element to work with. **Third,** we assume we have some monoid `(+,0)`

. Our `+`

operator is going to act like non-deterministic choice in regexes— but, we're not going to assume that it's commutative! That is, while it represents "choice", it's some sort of *biased choice*. Maybe we always try the left option first; or maybe we always try the right option first; or maybe we flip a biased coin and try the left option first only 80% of the time; whatever, the point is it's not entirely non-deterministic, so we can't simply flip our additions around. **Finally,** we require that our `(*)`

semigroup distributes *from the right* over our `(+,0)`

monoid (or conversely, that we can factor the monoid out from under the semigroup, again only factoring out parts that are on the *right*). That is, symbolically, we require the following two laws to hold:

`0*x = 0`

`(x+y)*z = (x*z)+(y*z)`

So, what have we done here? Well, we have these two interlocking operations where "catenation" distributes over "choice". What the first law mean is that: (1) if we first do something absurd or impossible and then do `x`

, well that's impossible. We'll never get around to doing `x`

so we might as well just drop that part. The second law means: (2) if we first have a choice between `x`

and `y`

and then we'll catenate whichever one with `z`

, this is the same as saying our choice is really between doing `x`

followed by `z`

vs doing `y`

followed by `z`

.

### MonadPlus

Okay, so what does any of this have to do with `MonadPlus`

? Intuitively, our `*`

operator is performing catenation or sequencing of things. Monads are all about sequencing. So how about we use the monad operator `(>>)`

as our "multiplication"! This does what we need it to since `(>>)`

is associative, by the monad laws. In order to turn a monad into a `MonadPlus`

we must define `mplus`

(aka the `+`

operator) and we must define a `mzero`

(aka the `0`

element). And the laws our `MonadPlus`

instance must uphold are just the two laws about distributing/factoring on the right. In restating them below, I'm going to generalize the laws to use `(>>=)`

in lieu of `(>>)`

:

`mzero >>= f = mzero`

`(x `mplus` y) >>= f = (x >>= f) `mplus` (y >>= f)`

And the reason why these laws make sense are just as described before. If we're going to "fail" or do something absurd followed by doing something else, well we'll never get around to that something else because we've already "failed". And if we first make a choice and then end up doing the same thing regardless of the choice we made, well we can just push that continuation down underneath the choice.

Both of these laws make intuitive sense for what we want out of `MonadPlus`

. And given that seminearrings are something which have shown up often enough to be named, it seems reasonable to assume that's the actual pattern we're trying to capture. The one sticking point I could see is my generalization to using `(>>=)`

. In the second law, we allow `f`

to be a function which "looks inside" the monad, rather than simply being some fixed monadic value `z`

. There's a chance that some current `MonadPlus`

implementations will break this law because of that insight. If so, then we can still back off to the weaker claim that `MonadPlus`

should implement a right-seminearring *exactly*, i.e., with the `(>>)`

operator as our notion of multiplication/catenation. This I leave as an exercise for the reader. This is discussed further in the addendum below.

Notably, from these laws it is impossible to derive `x*0 = 0`

, aka `x >> mzero = mzero`

. And indeed that is a stringent requirement to have, since it means we must be able to undo the "effects" of `x`

, or else avoid doing those "effects" in the first place by looking into the future to know that we will eventually "fail". If we could look into the future to know we will fail, then we could implement backtracking search for logic programming in such a way that we *always pick the right answer.* Not just return results consistent with always choosing the right answer, which backtracking allows us to do; but rather, to always know the right answer beforehand and so never need to backtrack! If we satisfy the `x*0 = 0`

law, then we could perform all the "search" during compile time when we're applying the rewrite rule associated with this law.

### Addendum

There's a long history of debate between proponents of the generalized distribution law I presented above, vs the so-called "catch" law. In particular, `Maybe`

, `IO`

, and `STM`

obey the catch law but do not obey the generalized distribution law. To give an example, consider the following function:

`f a' = if a == a' then mzero else return a'`

Which is used in the following code and evaluation trace for the `Maybe`

monad:

`mplus (return a) b >>= f`

`⟶ Just a >>= f`

`⟶ f a`

`⟶ if a == a then mzero else return a`

`⟶ mzero`

As opposed to the following code and evaluation trace:

`mplus (return a >>= f) (b >>= f)`

`⟶ mplus (f a) (b >>= f)`

`⟶ mplus mzero (b >>= f)`

`⟶ b >>= f`

But `b >>= f`

is not guaranteed to be identical to `mzero`

. The problem here is, as I suspected, because the generalized distribution law allows the continuation to "look inside". If we revert back to the non-generalized distribution law which uses `(>>)`

, then this problem goes away— at least for the `Maybe`

monad.

### Second Addendum (2014.02.06)

Even though `Maybe`

satisfies the non-generalized distributivity laws, it's notable that other problematic `MonadPlus`

instances like `IO`

fail even there! For example,

First consider `mplus a b >> (c >> mzero)`

. Whenever `a`

succeeds, we get that this is the same as `a >> c >> mzero`

; and if `a`

fails, then this is the same as `a' >> b >> c >> mzero`

where `a'`

is the prefix of `a`

up until failure occurs.

Now instead consider `mplus (a >> c >> mzero) (b >> c >> mzero)`

. Here, if `a`

succeeds, then this is the same as `a >> c >> b >> c >> mzero`

; and if `a`

fails, then it's the same as `a' >> b >> c >> mzero`

. So the problem is, depending on whether we distribute or not, the effects of `c`

will occur once or twice.

Notably, the problem we're running into here is exactly the same one we started out with, the failure of `x >> mzero = mzero`

. Were this law to hold for `IO`

(etc) then we wouldn't run into the problem of running `c`

once or twice depending on distributivity.

## (no subject)

6/2/14 09:56 (UTC)dorchardEdited 6/2/14 09:57 (UTC)## (no subject)

6/2/14 21:59 (UTC)winterkoninkje`(>>=)`

which gets in the way of this generalization. But if we're not generalizing the distributivity laws, then`Maybe`

forms a right-seminearring just fine.Is this what you had in mind:

`ma >>= (\a -> f a `mplus` g a) = (ma >>= f) `mplus` (ma >>= g)`

? If so, then this is definitely going to break for`IO`

etc. Just consider`ma = print "blah" >> mzero`

; one side of the proposed equation only prints once, whereas the other prints twice. So even if that happens to work out for`Maybe`

, it's not really a solution to what`MonadPlus`

should mean.