Hi Maciej On 30 Dec 2009, at 00:07, Maciej Piechotka wrote:
On Tue, 2009-12-29 at 23:00 +0000, Conor McBride wrote:
Hi Maciej
On 29 Dec 2009, at 20:52, Maciej Piechotka wrote:
On Tue, 2009-12-29 at 18:20 +0000, Conor McBride wrote:
ala AppLift foldMap
What is benefit of it over: concatMapA f = foldr (liftA2 mappend . f) (pure mempty)
Given that applicative functors take monoids to monoids, it's nice to exploit that property by name, rather than reconstructing it by engineered coincidence.
I wouldn't state it as 'coincidence'. I don't need to create explicit map where implicit (liftA2 mappend and pure mempty) is sufficient.
The coincidence I mean is *between* liftA2 mappend and pure mempty: those are the pieces of a lifted monoid, without the observation that that's what's going on.
In this case I have one line when you have many (however it might be other case with more complicated examples - but I don't quite see how)[1].
It depends how you count. I have three symbols. The rest may not be in the standard library, but it's in my library. I certainlt wouldn't propose setting up that machinery just for that one problem. But if you google, you'll find I've suggested it several times, for a number of different problems.
Also I'm not quite sure if ala is something general and therefore should be exposed instead of just putting it. But I may be wrong
I've been programming with ala for some years now. I find it really useful. Zooming out a bit, I think there's a very healthy trend to introduce type distinctions at a finer level than is necessary for purposes of data representation, just to put a particular structural spin on things. The payback from that is writing less code, provided your library is set up to exploit richer type information.
[1] http://www.willamette.edu/~fruehr/haskell/evolution.html ;)
Quite so. I like evolving. All the best Conor