[Haskell-cafe] Re: Re: Re: (liftM join .) . mapM

[Maciej Piechotka]

On Wed, 2009-12-30 at 00:45 +0000, Conor McBride wrote:
> 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.
> 

Hmm. Without explicit *writing* that it is what is going on. They are as
coincidental as using return and >>= together - they are mappings
betwean functions operating in specific domains (pure is liftA0, liftA
is liftA1).

> > 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.
> 

Hmm. I would rather count per program. And, at least now, in increase
length of program. However if [a) 'program' is a library and we get
increased generalisation then increased length migh be justified b) we
get more type safty c) we reuse it so many times in program the increase
of code is not significant] it is a bit different matter.

> > 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.
> 

While I agree in general I would rather limit it to between-function
methods and when it suits in function. For example I had pice of code
which was basicly state transformation composed by state
transformations. Something similar to:

myFunc :: Int -> State MyState Result

However I found it clearer to have explicit let as transformations:

  let (v, s') = something s
      (v', s'') = somethingElse s' 
  in somethingCompletlyDifferent v v' s''

And have signatures of ... -> MyState -> MyState. Well OK. It was state
transformation. It is sometimes useful to have a finer level. But
sometimes it's easier not to have it (sorry for gramar structure).

> All the best
> 

The same to you