Proposal #2717: Add nubWith, nubOrd

Mitchell, Neil neil.mitchell.2 at credit-suisse.com
Thu Oct 23 03:30:20 EDT 2008


Hi

> >> Were we to keep it, do you have a better naming suggestion?
> > 
> > [Warning: untested code]
> > 
> > filterAccum :: (acc -> x -> (acc,Bool)) -> acc -> [x] -> (acc, [x]) 
> > filterAccum f a [] = (a, []) filterAccum f a (x:xs) = (an, 
> > [x|b]++rest)
> >    where (a2,b) = f a x
> >          (an,rest) = filterAccum f a2 xs
> > 
> > This follows the type of mapAccumL, and is more general than your 
> > function.
> 
> can we call it filterAccumL then?  It took me a while to 
> figure out from the code whether it was truly an "L" or "R" 
> version, and in principle there could be filterAccumR 
> (although I don't know why we'd want it)

Yes, that would be the sensible name. However, I don't think it deserves
to be in the standard libraries :-)

If anyone feels it should be, that sounds like it should be a separate
proposal from nubOrd.

> > You could change the utility function to be (acc -> x -> (acc,Maybe 
> > y)) to get a variant that is more general than both mapAccum and 
> > filterAccum.
> 
> in which case the result type would be (acc, [y]), and it 
> would have a similar type and semantics to 
> Data.Maybe.mapMaybe :: (a -> Maybe b) -> [a] -> [b]
> 
> .. maybeAccumL? :-)

Yes, that does seem like the correct name for it. Again, I don't think
it's a massively useful function - the Accum functions just aren't as
useful anymore now Monads are better understood.

Thanks

Neil

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================



More information about the Libraries mailing list