Should Foundation keep historical artefacts?

[AnthonyJacob]

I am looking at you

foldl
return 
append
-- feel free to add more

Even if it doesn't look like an important decision (at least before Foundation 1.0 is out), you should could consider that the longer will they be present, the more parts of Foundation might misuse them.

[vincenthz]

This is an extremely interesting and difficult question, with probably no right answers.

So basically I'm all up to remove all sort of historical artefacts, and in places foundation already provided this; But, I see this as a balancing act with the following too:

• not break too far apart from current haskell for migration purpose: not providing current combinators (or renaming them) make it difficult to migrate projects
• Reimplementing core classes like Monoid and Monad, is useful so that we're not locked by old legacy choices, but is not trivial. Specially in a project where you might want to mix with current haskell way (through foundation-edge), then you'll have to juggle different monoid, semigroups, monad concepts.

To name some example:

• Monoid has a mconcat which is biased to list: it would be nice to remove this constraint so that we can mconcat any collection.
• Semigroup has a bias on list with the NonEmpty: we already provide a NonEmpty which is better than the base one and thus not compatible with NonEmpty and semigroup in base.
• Monad is intertwined with the compiler (just like Num). You can't reasonably define your own class.

[mgsloan]

I certainly agree with generalizing and renaming as appropriate. In particular, I think we should do away with mappend. It's not really a very sensible name for (<>) (I prefer the Semigroup operator). I'm sure more will occur to me in the future :)

[vincenthz]

I'm experimenting with some stuff that allow to get away from the haskell syntax dependent issue (Monad, literals), so I'm warming with the idea of to have a clean break and do what make sense.

Some of my experiments: https://gist.github.com/vincenthz/51c0a7f04ae199a28d2249e67a7833ab

[AnthonyJacob]

I have met scheme in the mean time where almost any function is polyvariadic and I realized that zipWith is actually map2.

It get's a little bit funny when you start to think about what map0 should do. Either replicate or repeat would I say.