generalization of maybeToList

[Edward Kmett]

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 at 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 at haskell.org
> (all of which only *referenced* it, without defining it).
>
> -Brent
>
> >
> > On Tue, Feb 14, 2012 at 10:47 AM, Jeff Shaw <shawjef3 at 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 at 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 at haskell.org
> > >>> http://www.haskell.org/**mailman/listinfo/libraries<
> http://www.haskell.org/mailman/listinfo/libraries>
> > >>>
> > >>
> > >
>
> > _______________________________________________
> > Libraries mailing list
> > Libraries at haskell.org
> > http://www.haskell.org/mailman/listinfo/libraries
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120214/997541f0/attachment.htm>