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