generalization of maybeToList

Jeff Shaw

14 Feb 2012 14 Feb '12

9:55 a.m.

I find myself using this function quite a lot. I believe it should be included in Data.Maybe. import Control.Monad maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

Show replies by date

Edward Kmett

14 Feb 14 Feb

10:24 a.m.

If you are going to add one then the generalization of your generalization to Alternative might be better. maybeA = maybe empty pure On Feb 14, 2012, at 9:55 AM, Jeff Shaw wrote:

...

I find myself using this function quite a lot. I believe it should be included in Data.Maybe.

import Control.Monad

maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Jeff Shaw

10:47 a.m.

I'm all for generalizations! I have a second, very similar function I think should be added, but I don't have a good name for it. maybe mzero id :: MonadPlus m => Maybe (m a) -> m a Perhaps there is once again an equivalent for Alternative. On 2/14/2012 10:24 AM, Edward Kmett wrote:

...

If you are going to add one then the generalization of your generalization to Alternative might be better.

maybeA = maybe empty pure

On Feb 14, 2012, at 9:55 AM, Jeff Shaw wrote:

...
I find myself using this function quite a lot. I believe it should be included in Data.Maybe.

import Control.Monad

maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Edward Kmett

3:36 p.m.

The biggest problem is that with each one of these being so short and with so many useful variations, the concepts struggle to cross the "Fairbairn threshold". On Tue, Feb 14, 2012 at 10:47 AM, Jeff Shaw wrote:

...

I'm all for generalizations! I have a second, very similar function I think should be added, but I don't have a good name for it.

maybe mzero id :: MonadPlus m => Maybe (m a) -> m a

Perhaps there is once again an equivalent for Alternative.

On 2/14/2012 10:24 AM, Edward Kmett wrote:

...
If you are going to add one then the generalization of your generalization to Alternative might be better.

maybeA = maybe empty pure

On Feb 14, 2012, at 9:55 AM, Jeff Shaw wrote:

I find myself using this function quite a lot. I believe it should be

...
included in Data.Maybe.

import Control.Monad

maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

Brent Yorgey

4:02 p.m.

On Tue, Feb 14, 2012 at 03:36:22PM -0500, Edward Kmett wrote:

...

The biggest problem is that with each one of these being so short and with so many useful variations, the concepts struggle to cross the "Fairbairn threshold".

What is the "Fairbairn threshold"? I tried doing a Google search for it, and all I got was a bunch of messages from libraries@haskell.org (all of which only *referenced* it, without defining it). -Brent

...

On Tue, Feb 14, 2012 at 10:47 AM, Jeff Shaw wrote:

...
I'm all for generalizations! I have a second, very similar function I think should be added, but I don't have a good name for it.

maybe mzero id :: MonadPlus m => Maybe (m a) -> m a

Perhaps there is once again an equivalent for Alternative.

On 2/14/2012 10:24 AM, Edward Kmett wrote:

...
If you are going to add one then the generalization of your generalization to Alternative might be better.

maybeA = maybe empty pure

On Feb 14, 2012, at 9:55 AM, Jeff Shaw wrote:

I find myself using this function quite a lot. I believe it should be

...
included in Data.Maybe.

import Control.Monad

maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

...

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Edward Kmett

7:23 p.m.

The Fairbairn threshold is the point at which the effort of looking up or keeping track of the definition is outweighed by the effort of rederiving it or inlining it. The term was in much more common use several years ago. Adding every variant on every operation to the Prelude is certainly possible given infinite time, but this of course imposes a sort of indexing overhead mentally. The primary use of the Fairbairn threshold is as a litmus test to avoid giving names to trivial compositions, as there are a potentially explosive number of them. In particular any method whose definition isn't much longer than its name (e.g. fooBar = foo . bar) falls below the threshold. There are reasonable exceptions for especially common idioms, but it does provide a good rule of thumb. The effect is to encourage simple combinators that can be used in multiple situations, while avoiding naming the explosive number of combinations of those combinators. Given n combinators I can probably combine two of them in something like O(n^2) ways, so without the threshold as a rule of thumb you wind up with a much larger library, but no real greater utility and much higher cognitive overhead to track all the combinations. Further, the existence of some combinations tends to drive you to look for other ever larger combinations rather than learn how to compose combinators or spot the more general usage patterns yourself, so from a POSIWID perspective, the threshold encourages better use of the functional programming style as well. -Edward On Tue, Feb 14, 2012 at 4:02 PM, Brent Yorgey wrote:

...

On Tue, Feb 14, 2012 at 03:36:22PM -0500, Edward Kmett wrote:

...
The biggest problem is that with each one of these being so short and with so many useful variations, the concepts struggle to cross the "Fairbairn threshold".

What is the "Fairbairn threshold"? I tried doing a Google search for it, and all I got was a bunch of messages from libraries@haskell.org (all of which only *referenced* it, without defining it).

-Brent

...
On Tue, Feb 14, 2012 at 10:47 AM, Jeff Shaw wrote:

...
I'm all for generalizations! I have a second, very similar function I think should be added, but I don't have a good name for it.

maybe mzero id :: MonadPlus m => Maybe (m a) -> m a

Perhaps there is once again an equivalent for Alternative.

On 2/14/2012 10:24 AM, Edward Kmett wrote:

...
If you are going to add one then the generalization of your generalization to Alternative might be better.

maybeA = maybe empty pure

On Feb 14, 2012, at 9:55 AM, Jeff Shaw wrote:

I find myself using this function quite a lot. I believe it should be

...
included in Data.Maybe.

import Control.Monad

maybeTo :: (MonadPlus m) => Maybe a -> m a maybeTo = maybe mzero return

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries<

http://www.haskell.org/mailman/listinfo/libraries>

...
...
...
...
...
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Jeff Shaw

8:03 p.m.

If we want to argue about maybeTo and the Fairbairn threshold, probably we should argue about whether to include maybeToList, which is less general than maybeTo. Jeff

Conor McBride

15 Feb 15 Feb

4:30 a.m.

On 15 Feb 2012, at 01:03, Jeff Shaw wrote:

...

If we want to argue about maybeTo and the Fairbairn threshold, probably we should argue about whether to include maybeToList, which is less general than maybeTo.

and only a fraction shorter than foldMap pure or, as it is in the Epigram codebase trail :: (Applicative f, Foldable t, Monoid (f a)) => t a -> f a trail = foldMap pure "a trail told by an idiom..." being the joke at the time. It would do listToMaybe as well, if the Monoid instance for Maybe captured the prioritized choice semantics. It would be interesting to apply the Fairbairn threshold retrospectively and see what could be cheaply replaced by suitable deployment of Applicative/Traversable/Foldable/Monoid and (crucially) Control.Newtype. Instead of remembering lots of names of functions, get types to remember things for you! Or something. Gotta run Conor

Edward Kmett

10:59 a.m.

On Tue, Feb 14, 2012 at 8:03 PM, Jeff Shaw wrote:

...

If we want to argue about maybeTo and the Fairbairn threshold, probably we should argue about whether to include maybeToList, which is less general than maybeTo.

This is a much harder sell, because it has to overcome the fact that such a change for the sake of intellectual purity would break existing code needlessly. The fact that this becomes a consideration is further argument against carelessly expanding the library. I'm not saying that the combinators under discussion are a careless expansion, merely that their addition needs to be weighed against those other concerns. I'm still a lukewarm +1 for adding maybeTo/maybeA if better names can be derived. Annoyingly it doesn't fit any of the m prefix or M suffix guidelines in Control.Monad, so the obvious maybeM or mmaybe would be misapplied. -Edward

Nils Anders Danielsson

4:36 a.m.

On 2012-02-14 22:02, Brent Yorgey wrote:

...

What is the "Fairbairn threshold"? I tried doing a Google search for it, and all I got was a bunch of messages from libraries@haskell.org (all of which only *referenced* it, without defining it).

I believe that the term refers to what Jón Fairbairn wrote in the following message: Names for small functions: just say no... Re: Data.List.join http://thread.gmane.org/gmane.comp.lang.haskell.libraries/5280/focus=5355 Ross Paterson seems to have coined the term later the same day in a message to the same mailing list: proposed addition to System.IO http://thread.gmane.org/gmane.comp.lang.haskell.libraries/5325/focus=2029 For those following the list at the time it should have been obvious what the term referred to. -- /NAD

4844

Age (days ago)

4845

Last active (days ago)

List overview

Download

9 comments

5 participants

participants (5)

Brent Yorgey
Conor McBride
Edward Kmett
Jeff Shaw
Nils Anders Danielsson