On Fri, 7 Dec 2007, Simon Peyton-Jones wrote: > | And I think that the solution is not to make the language larger and larger > | everytime someone wants a feature but to give people the tools to provide > | features without language changes. > > Of course that would be even better! (Provided of course the resulting > programs were comprehensible.) Haskell is already pretty good in this > respect, thanks to type classes, higher order functions, and laziness; > that's why it's so good at embedded domain-specific languages.
When I learned about GROUP BY and HAVING in SQL with its rules about what is allowed in GROUP BY and SELECT I considered GROUP BY a terrible hack, that was just introduced because the SQL people didn't want to allow types different from TABLE, namely lists of tables. I try to convince my data base colleagues that GROUP BY can nicely be handled in relational algebra by allowing sets of sets and that this is a fine combinatorial approach. I think we simply need a function like buckets :: (a -> key) -> [a] -> [(key, [a])] (where (a -> key) is a simple selector) or buckets :: (a -> (key, rest)) -> [a] -> [(key, [rest])] (where (a -> (key, rest)) is a bijection) or buckets :: Ord key => ... ah no :-) buckets :: Indexable key => (a -> (key, rest)) -> [a] -> Map key [rest] buckets f = Map.fromListWith (++) . map (\ a -> let (k,r) = f a in (k, [r])) Btw. since I often need fromListWith with Maps of list types, I wonder whether there should be variants of fromListWith and insertWith, which can use (:) instead of (++): fromListCons :: Indexable k => (b -> a -> a) -- ^ add a new sub-element to the dictionary element, for example (:) -> a -- ^ empty dictionary element, for example [] -> [(k, b)] -> Data.Map.Map k a insertCons :: Indexable k => (b -> a -> a) -> a -> k -> b -> Data.Map.Map k a -> Data.Map.Map k a _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe