On 30 Dec 2009, at 00:07, Maciej Piechotka wrote:
On Tue, 2009-12-29 at 23:00 +0000, Conor McBride wrote:
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.
this case I have one line when you have many (however it might be
case with more complicated examples - but I don't quite see how).
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
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.
Quite so. I like evolving.
All the best
Haskell-Cafe mailing list