On Thu, 02 Nov 2006, Malcolm Wallace wrote:

However, the "Control." hierarchy is certainly the wrong place for it. The very name Control is intended to suggest things that are slightly outside the usual functional domain - more in the region of imperative control structures.

In that case, why do we have Control.Applicative, Control.Arrow etc., which are purely functional? The only non-functional libraries are those that involve the IO or ST monads (Control.Concurrent, Control.Exception, Control.Monad.ST, etc.). Personally I prefer Data.Function (to match Data.Tuple, etc.), but it doesn't really seem to match the current division between Data and Control. Many nice little combinators (like (&&&) and (***)) can be found in Control.Arrow, for instance. -- /NAD

Hello Malcolm, Thursday, November 2, 2006, 9:00:00 PM, you wrote:

Control.Arrow is alongside Control.Monad.

I'm not sure that there is a good word to describe all these such things that are more structured than mere data. Perhaps they should really live in a "Category." hierarchy, or "Idiom." (not to be confused with Conor's use of the term), or "Abstract." ?

perhaps Monsters.* ? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hello Malcolm, Thursday, November 2, 2006, 8:18:25 PM, you wrote:

...

(*) `on` f = \x y -> f x * f y

Here are some alternative suggestions:

Data.Function Data.Functional Prelude.Functional Function.Combinators Prelude.Combinators

also Data.Combinators -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hi

also Data.Combinators

Combinators "combine things" - depending on your exact definition of combinators pretty much anything can be a "combinator". My System.FilePath has been called a combinator library by some people. I'd rather avoid terms like Combinator (and Idiom, unless in the very specific sense of Connor's work) which tend to increase in scope as time goes by. Data.Function seems a much more appropriate place, or perhaps just Function on its own. (Maybe we need a Function.* heirarchy?) Thanks Neil

Since Data.Ord and Data.Eq now have there on modules and are part of the prelude, I suggest to create Data.Function and put in "flip", "id", "const" (did I forget one?) and "on". The prelude need/should not reexport "on", though. 1. I agree to have comparing and equating separately (however implemented) 2. Data.Function seems right to me, too (because "Data.->" is illegal as module identifier) Christian Duncan Coutts schrieb:

I agree it should go in.

I wonder about how this relates to 'comparing' which we already have in Data.Ord. Does adding 'on' mean we should remove 'comparing' ?

I would suggest we keep both and add 'equating' to Data.Eq too, for symmetry with 'comparing'.

Why? Because for the cases covered by comparing/equating I think the code feel simpler and reads more naturally.

In my own code I think I would use comparing/equating when using the ordinary Ord/Eq instances and use `on` when I was using a non-standard comparison.

Duncan

On Thu, 2006-11-02 at 18:00 +0100, Nils Anders Danielsson wrote:

...

The function on defined by

(*) `on` f = \x y -> f x * f y

is convenient when using functions like sortBy: sortBy (compare `on` fst), for example. It also makes the code more readable.

Furthermore I consider on to be above the Fairbairn threshold, since * we get rid of two lambdas, * we get rid of the duplication of p, * on has some nice algebraic properties (documented in the patch) * and, most importantly, it is easier at a glance to understand (*) `on` p than to understand \x y -> p x * p y (assuming one knows about on).

Nils Anders Danielsson schrieb:

On Fri, 03 Nov 2006, Christian Maeder wrote:

...

Since Data.Ord and Data.Eq now have there on modules and are part of the prelude, I suggest to create Data.Function and put in "flip", "id", "const" (did I forget one?) and "on".

You forgot (.) and ($), which are already included.

Right, although I did look into your code I overlooked your re-export, because I expected the implementation of these function to be in the module whereas the prelude should re-export parts of it (Data.Function). However, the "true origin" of a function does not seem to matter and I don't know if Data.Ord re-exports parts of the Prelude or vice versa.

I didn't include seq, ($!) or asTypeOf.

Good, Christian

Hello Duncan, Friday, November 3, 2006, 1:21:13 AM, you wrote:

I wonder about how this relates to 'comparing' which we already have in Data.Ord. Does adding 'on' mean we should remove 'comparing' ?

I would suggest we keep both and add 'equating' to Data.Eq too, for symmetry with 'comparing'.

i greatly support this idea. otherwise, we will make laguage understandable only by postgraduates. we shouldn't remove simple features from the libs only because there more complex ways to do the same. as far as it is easier to understand/has a lot of uses, simple feature should exist with their generalizations -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

On Fri, 2006-11-03 at 13:23 +0100, Nils Anders Danielsson wrote:

On Thu, 02 Nov 2006, Duncan Coutts wrote:

...

I wonder about how this relates to 'comparing' which we already have in Data.Ord. Does adding 'on' mean we should remove 'comparing' ?

I would suggest we keep both and add 'equating' to Data.Eq too, for symmetry with 'comparing'.

I think it's just as easy to understand (compare `on` f) as (comparing f), so having both just adds extra complexity. Hence I place comparing _under_ the Fairbairn threshold.

groupBy ((==) `on` fst) vs groupBy (equating fst) well, I disagree. Yes it's a special case, but I would use it in the common special case and use `on` in the rarer general case. But no matter. So do you suggest that we deprecate and remove comparing? Or do you think we should have comparing but not equating, leaving it asymmetric and just claim that comparing was added too soon but couldn't be removed? If the latter then perhaps you want to add a comment to the comparing docs: Don't use @comparing foo@, use @compare `on` foo@. Duncan

On Nov 3, 2006, at 11:58 AM, Bulat Ziganshin wrote:

while we are here, i also propose to export from Data.List 'merge' function that is useful on its own

Yes, please. This qualifies as my most commonly rewritten multi-line Haskell function. That said, I've also written most of the variations of merge you might care to imagine (indeed, sorted-list sets and multisets together use pretty much all of them if you include difference and merging of equals). -Jan-Willem Maessen

-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Duncan Coutts schrieb:

So start a new thread and lets try and find out if there is a consensus.

As an example variation from a program I wrote:

-- mergeBy cmp xs ys = (only_in_xs, in_both, only_in_ys)

mergeBy :: (a -> b -> Ordering) -> [a] -> [b] -> ([a], [(a, b)], [b]) mergeBy cmp = merge [] [] [] where merge l m r [] ys = (reverse l, reverse m, reverse (ys++r)) merge l m r xs [] = (reverse (xs++l), reverse m, reverse r) merge l m r (x:xs) (y:ys) = case x `cmp` y of GT -> merge l m (y:r) (x:xs) ys EQ -> merge l ((x,y):m) r xs ys LT -> merge (x:l) m r xs (y:ys)

It's rare of course that you need the generality of merging lists of different types. Though of course this also covers the slightly more common case of comparing where == is only an equivalence relation and you want to keep or combine both elements.

I've found the following generalization sufficient enough: merge :: (a -> a -> Ordering) -> (a -> a -> [a] -> [a]) -> [a] -> [a] -> [a] merge cmp jn l1 l2 = case l1 of [] -> l2 x1 : r1 -> case l2 of [] -> l1 x2 : r2 -> let recmerge = merge cmp jn in case cmp x1 x2 of LT -> x1 : recmerge r1 l2 EQ -> jn x1 x2 $ recmerge r1 r2 GT -> x2 : recmerge l1 r2 Add a parameter to join equal elements with the recursively merged list tails. This allows to keep both or only one elements or to add occurrences counts of multi-sets. Cheers Christian

Nils Anders Danielsson schrieb:

On Fri, 03 Nov 2006, Duncan Coutts wrote:

...

groupBy ((==) `on` fst)

Read it as "group by equality on first".

...

vs groupBy (equating fst)

...

So do you suggest that we deprecate and remove comparing?

Yes, this seems like a good idea. (I had forgotten that comparing was added before 6.6 was released.) I can add a deprecation pragma to my patch. Any objections?

Yes, "comparing" is mentioned in "ThingsToAvoid". Adding "equating" does do no harm. Style choices should be left to the user. Christian

I agree with Duncan here, and I'd prefer to keep all three. On 03/11/06, Duncan Coutts wrote:

On Fri, 2006-11-03 at 18:05 +0100, Nils Anders Danielsson wrote:

...

On Fri, 03 Nov 2006, Duncan Coutts wrote:

...

groupBy ((==) `on` fst)

Read it as "group by equality on first".

...

vs groupBy (equating fst)

...

So do you suggest that we deprecate and remove comparing?

Yes, this seems like a good idea. (I had forgotten that comparing was added before 6.6 was released.) I can add a deprecation pragma to my patch. Any objections?

As I've said before, I think there is room for both the general and special cases. We're not talking about polluting the namespace here, Data.Ord and Data.Eq are pretty new and have to be imported explicitly. It's not like adding something to Data.List which many existing programs import without qualification.

But mainly I think it should be consistent. We should either have all three or just `on`. Keeping comparing but not adding equating doesn't seem to make a lot of sense. We should either agree to deprecate comparing or add equating too.

So now that we have `on`, is there any desire for comparing and equating. I think there is, but lets see what other people think.

Duncan

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Fri, 03 Nov 2006, Duncan Coutts wrote:

But mainly I think it should be consistent. We should either have all three or just `on`. Keeping comparing but not adding equating doesn't seem to make a lot of sense. We should either agree to deprecate comparing or add equating too.

This I agree with, and having all three isn't the end of the world, so it's fine with me. Do we have a patch for equating fulfilling all the new requirements? -- /NAD