[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haskell-cafe
Subject:    Re: [Haskell-cafe] Re: Re: (liftM join .) . mapM
From:       Conor McBride <conor () strictlypositive ! org>
Date:       2009-12-30 0:45:25
Message-ID: 84962617-FD40-4603-B8F3-7FF835FC7C74 () strictlypositive ! org
[Download RAW message or body]

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

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[prev in list] [next in list] [prev in thread] [next in thread]