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

[Carter Schonwald]

good point: the core libraries really should strike a balance between
generality, consistency, and having informative / useful type inference for
client users.

by the criterion, the foldable and traversable in prelude fits that
objective to a T. (but i'm just repeating what other people have already
said I suppose)


On Tue, May 21, 2013 at 5:27 PM, Edward Kmett <ekmett at gmail.com> wrote:

> 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>
>>
>
>
> _______________________________________________
> 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/20130521/6e5227a8/attachment.htm>