foldable flexible bridges (putting foldable+traversable in prelude) Re: Burning bridges

[Edward Kmett]

One nice thing about the limited palette of tools we're generally willing
to allow ourselves in the base libraries is that it steers us towards a
pretty reasonable middle ground.

Since MPTCs and fundeps are off the table for the forseeable future in
terms of Prelude library design, we're more or less forced into the subset
of Haskell that works and infers nicely. Is what Foldable/Traversable allow
us to build strictly the most general thing that could be built? No -- but
it does tend to run a pretty good balance between rigorous laws,
flexibility, ease of understanding, and inference.

When I see these pie in the sky options about generalizing everything away
almost universally those rely on extensions that frankly don't infer well.

Foldable and Traversable do not rise to that level of complexity and can be
implemented entirely within a framework we've had fully fleshed out for 15
years.

When is it enough to just integrate an improvement and move on? Should we
try again at 30 years or do you think someone might have accidentally
written another book in the meantime?

-Edward


On Tue, May 21, 2013 at 4:44 PM, Henning Thielemann <
lemming at henning-thielemann.de> wrote:

>
> On Tue, 21 May 2013, Casey McCann wrote:
>
>  Being a beginner is by definition an ephemeral state; the entire
>> purpose of being a beginner is to eventually stop being one. Don't
>> design a language (or anything else) around the needs of beginners
>> unless you intend that only beginners will use it, in which case one
>> wonders why they're even bothering.
>>
>
> The other way round does not work, too. If you are trying to put the most
> general (thus most "useful" function) to Prelude, you will find that there
> will always be more general generalizations. Today you say
>
>   mapM_ :: (a -> m b) -> [a] -> m ()
>
> should be replaced by more general
>
>   mapM_ :: (a -> m b) -> f a -> m ()
>
> But this is not the most general form. We have discussed several times
> about generalizing the (), without a conclusion. But maybe some day there
> might be consensus to generalize the () away ... what will be the next
> generalization? We may generalize the (->) away. What else?
>
> For me it is perfect to start with something simple in Prelude and build
> more general functions around it in other modules. This is a scheme that we
> can manage over time with backwards compatibility.
>
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130521/2393db97/attachment.htm>