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 <byorgey@seas.upenn.edu> 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 <shawjef3@msu.edu> 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<shawjef3@msu.edu>  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