Hello, and welcome me to the list I think it would often be useful if the list functions with class constraints had versions paramaterized on a function mapping your element type into an instance of the classes, in addition to the "By" forms that take an implementation for the required class method. Almost all of the times I use the "By" functions follow that pattern: e.g. sortFoos :: [Foo] -> [Foo] sortFoos = sortBy (\x y -> compare (f x) (f y)) I suggest "Under" as a modifier. "By" would be nice (as in "sortBy fst", "sortBy valueOf", etc) but it's already taken. We are using the image under some function to control the list munging, so it seems appropriate. How does this sound? Brandon Moore
On Fri, Jan 16, 2004 at 01:43:40AM -0800, Brandon Michael Moore wrote:
Hello, and welcome me to the list
Welcome to the list! :)
I think it would often be useful if the list functions with class constraints had versions paramaterized on a function mapping your element type into an instance of the classes, in addition to the "By" forms that take an implementation for the required class method.
Almost all of the times I use the "By" functions follow that pattern: e.g. sortFoos :: [Foo] -> [Foo] sortFoos = sortBy (\x y -> compare (f x) (f y))
No need for so many new functions. Just write a function: composeFGxGy :: (b -> b -> c) -> (a -> b) -> a -> a -> c composeFGxGy f g x y = f (g x) (g y) Then you can: sortFoos = sortBy (composeFGxGy compare f)
How does this sound?
And how does _this_ sound? ;) Best regards, Tom -- .signature: Too many levels of symbolic links
On Fri, Jan 16, 2004 at 11:03:21AM +0100, Tomasz Zielonka wrote:
On Fri, Jan 16, 2004 at 01:43:40AM -0800, Brandon Michael Moore wrote:
I think it would often be useful if the list functions with class constraints had versions paramaterized on a function mapping your element type into an instance of the classes, in addition to the "By" forms that take an implementation for the required class method.
Almost all of the times I use the "By" functions follow that pattern: e.g. sortFoos :: [Foo] -> [Foo] sortFoos = sortBy (\x y -> compare (f x) (f y))
No need for so many new functions. Just write a function:
composeFGxGy :: (b -> b -> c) -> (a -> b) -> a -> a -> c composeFGxGy f g x y = f (g x) (g y)
Then you can:
sortFoos = sortBy (composeFGxGy compare f)
The special case may be useful if f is expensive: -- sortImage f = sortBy (\x y -> compare (f x) (f y)) sortImage :: Ord b => (a -> b) -> [a] -> [a] sortImage f xs = map snd (sortBy cmp_fst [(f x, x) | x <- xs]) where cmp_fst (x,_) (y,_) = compare x y
On Fri, Jan 16, 2004 at 12:01:42PM +0000, Ross Paterson wrote:
No need for so many new functions. Just write a function:
composeFGxGy :: (b -> b -> c) -> (a -> b) -> a -> a -> c composeFGxGy f g x y = f (g x) (g y)
Then you can:
sortFoos = sortBy (composeFGxGy compare f)
The special case may be useful if f is expensive:
-- sortImage f = sortBy (\x y -> compare (f x) (f y)) sortImage :: Ord b => (a -> b) -> [a] -> [a] sortImage f xs = map snd (sortBy cmp_fst [(f x, x) | x <- xs]) where cmp_fst (x,_) (y,_) = compare x y
Yes, you are right. But you are trading memory for speed, and in Haskell more memory sometimes means less speed. BTW. cmp_fst = composeFGxGy compare fst Best regards, Tom -- .signature: Too many levels of symbolic links
G'day all.
Quoting Brandon Michael Moore
Hello, and welcome me to the list
Welcome you!
Almost all of the times I use the "By" functions follow that pattern: e.g. sortFoos :: [Foo] -> [Foo] sortFoos = sortBy (\x y -> compare (f x) (f y))
Just noting that this particular example has a very simple solution: http://haskell.org/hawiki/SchwartzianTransform This technique probably doesn't solve all your problems, though. Cheers, Andrew Bromage
On Sat, Jan 17, 2004 at 08:24:45AM -0500, ajb@spamcop.net wrote:
Almost all of the times I use the "By" functions follow that pattern: e.g. sortFoos :: [Foo] -> [Foo] sortFoos = sortBy (\x y -> compare (f x) (f y))
Just noting that this particular example has a very simple solution:
http://haskell.org/hawiki/SchwartzianTransform
This technique probably doesn't solve all your problems, though.
It doesn't work when the type Foo doesn't belong to Ord class. There is a simple technique which helped me when I wanted to make a priority queue of elements with Double key, and IO () value. I wanted to use something from Edison, but most of relevant data structures didn't distinguish key from value and insisted that element type belong to Ord class. I just introduced a wrapper type that provides a trivial "Egalite" ordering. newtype NoOrd a = NoOrd { unNoOrd :: a } instance Eq (NoOrd a) where _ == _ = True instance Ord (NoOrd a) where _ `compare` _ = EQ Then I could store in the queue values of type (Double, NoOrd (IO ())) Best regards, Tom -- .signature: Too many levels of symbolic links
G'day all.
Quoting Tomasz Zielonka
It doesn't work when the type Foo doesn't belong to Ord class.
Right.
There is a simple technique which helped me when I wanted to make a priority queue of elements with Double key, and IO () value. I wanted to use something from Edison, but most of relevant data structures didn't distinguish key from value and insisted that element type belong to Ord class.
Yes. Edison priority queues are collections, not associations. This is a sufficiently common case that this might be worth thinking about for those working on a new collection system.
I just introduced a wrapper type that provides a trivial "Egalite" ordering.
Just added this to PreludeExts, though I called it OrdWrapper. (NoOrd suggests that it doesn't support Ord, whereas it's the underlying type which doesn't support Ord, or at least, you want to suppress its default Ord behaviour.) Cheers, Andrew Bromage
On Sat, Jan 17, 2004 at 10:00:23AM -0500, ajb@spamcop.net wrote:
I just introduced a wrapper type that provides a trivial "Egalite" ordering.
Just added this to PreludeExts, though I called it OrdWrapper. (NoOrd suggests that it doesn't support Ord, whereas it's the underlying type which doesn't support Ord, or at least, you want to suppress its default Ord behaviour.)
OK, I was going to mention that I don't like NoOrd name, but I forgot. I like OrdWrapper much better. Thanks! Best regards, Tom -- .signature: Too many levels of symbolic links
participants (4)
-
ajb＠spamcop.net -
Brandon Michael Moore -
Ross Paterson -
Tomasz Zielonka