- Libraries - Haskell.org

Re: Proposal #2659: Add sortOn and friends to Data.List
by Bertram Felgenhauer 09 Oct '08

09 Oct '08

Twan van Laarhoven wrote: > Hello list, > > > Almost all uses of sortBy in user code use 'comparing', 'on' or a similar > construction [1]. I think we should add a function that makes this common > behavior more convenient: > > sortOn :: Ord b => (a -> b) -> [a] -> [a] > > For consistency we should also add *On for the other *By functions in > Data.List: > > nubOn :: Eq b => (a -> b) -> [a] -> [a] > deleteOn :: Eq b => (a -> b) -> a -> [a] -> [a] > deleteFirstsOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > unionOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > intersectOn :: Eq b => (a -> b) -> [a] -> [a] -> [a] > groupOn :: Eq b => (a -> b) -> [a] -> [[a]] > sortOn :: Ord b => (a -> b) -> [a] -> [a] > insertOn :: Ord b => (a -> b) -> a -> [a] -> [a] > maximumOn :: Ord b => (a -> b) -> [a] -> a > minimumOn :: Ord b => (a -> b) -> [a] -> a > (nubSortOn :: Ord b => (a -> b) -> [a] -> [a]) -- see #2629 Too many functions, and too little added functionality, IMHO. > newtype Down a = Down { getDown :: a } I like this one. Bertram

2 1

Re: Status of nubOrd (Proposal #2629)
by Bertram Felgenhauer 09 Oct '08

09 Oct '08

Bart Massey wrote: > 1) Stick nubOrd' from my previous message into Data.List and > call it a day. I don't like it, for the simple reason that its exact strictness properties are hard to explain. Low performance hurts, too. > 2) Stick (non-StopList) nubWith in Data.List. Stick nubOrd > in Data.Set, implemented using nubWith. > > Advantages: Provides a highly efficient, fully lazy > nubOrd. Provides nubWith. Reasonable implementation. That's nubWith :: (a -> b -> Maybe b) -> b -> [a] -> [a], right? I have no strong opinion about this proposal either way. > Disadvantages: Sticking nubOrd in Data.Set is weird. That doesn't worry me much. We can always add a link to the documentation of 'nub'. All in all I must say that the design space for nub functions is surprisingly big. One aspect that hasn't been mentioned yet is special handling for finite types. For example, nubBool (True:True:False:undefined) could well return [True,False], because all possible values have been exhausted at that point. I'm not suggesting to add more functions for this - nubBool is easily expressed as nubBool = take 2 . nub regards, Bertram

3 3

cabal-install, ghc-6.10
by Johannes Waldmann 08 Oct '08

08 Oct '08

Does cabal-install work with ghc-6.10? Not out-of-the box it seems. With a recent 6.10 binary snapshot (containing Cabal-1.5.5), I get Configuring cabal-install-0.5.2... Setup: At least the following dependencies are missing: Cabal ==1.4.*, HTTP >=3000 && <3002, base <3 && >=2.0 && <2.2 Regards, J.W.

3 2

Re: A general question about the use of classes in defining interfaces
by Ross Paterson 08 Oct '08

08 Oct '08

On Wed, Oct 08, 2008 at 12:36:02PM +0200, S. Doaitse Swierstra wrote: > Stimulated by remarks made during the discussion on the future of > Haskell at the last Haskell Symposium, I have started to convert my new > parsing library (constructed for the Lernet summerschool in Uruguay) into > Cabalised form. In this library I have amongst others the class: > > class Applicative p where > (<*>) :: p (b -> a) -> p b -> p a > (<|>) :: p a -> p a -> p a > (<$>) :: (b -> a) -> p b -> p a > pReturn :: a -> p a > pFail :: p a > f <$> p = pReturn f <*> p > > which extends/deviates from the standard class Applicative, since I > think these functions more or less belong together. I am happy to factor > out <|> into a separate class. This corresponds to Alternative, a subclass of Applicative (except for <$> being a function instead of a method). They certainly belong together for parsers, but there are applicative functors that don't have the extra monoidal structure. > The problem which arises now is when I want to use the class Applicative > as it is now defined in Control.Applicative. Functions like <$>, <$, <* > and many have standard implementations in terms of the basic function pure > and <*>. Although this looks fine at first sight, this is not so fine if > we want to give more specialised (optimised, checking) implementations, > as I am doing in my library. An example of this is e.g. in many, where > I want to check that the parameter parser does not recognise the empty > sequence since thi is non-sense, etc. Of course we can describe <* by > > p <* q = pure const <*> p <*> q > > but this is also rather inefficient; why first building a result if you > are going to throw it away anyway? The current definition isn't quite as bad as that: p <* q = const <$> p <*> q f <$> a = fmap f a but the general point stands. > More in general I think it is preferred to place common patterns in > classes with a default implementation, so they can be redefined instead > of defining them at top level. > > 1) Does everyone agree with this observation, and if not what am I > missing? > 2) Can we change the module Applicative to reflect my view? I think it > can be done without implying heavy changes to other modules. This seems reasonable to me, as long as there aren't too many of them; we do this for lots of other classes. Would you like to list all the functions that you would like to have as redefinable methods?

2 1

A general question about the use of classes in defining interfaces
by S. Doaitse Swierstra 08 Oct '08

08 Oct '08

Stimulated by remarks made during the discussion on the future of Haskell at the last Haskell Symposium, I have started to convert my new parsing library (constructed for the Lernet summerschool in Uruguay) into Cabalised form. In this library I have amongst others the class: class Applicative p where (<*>) :: p (b -> a) -> p b -> p a (<|>) :: p a -> p a -> p a (<$>) :: (b -> a) -> p b -> p a pReturn :: a -> p a pFail :: p a f <$> p = pReturn f <*> p which extends/deviates from the standard class Applicative, since I think these functions more or less belong together. I am happy to factor out <|> into a separate class. The problem which arises now is when I want to use the class Applicative as it is now defined in Control.Applicative. Functions like <$>, <$, <* and many have standard implementations in terms of the basic function pure and <*>. Although this looks fine at first sight, this is not so fine if we want to give more specialised (optimised, checking) implementations, as I am doing in my library. An example of this is e.g. in many, where I want to check that the parameter parser does not recognise the empty sequence since thi is non-sense, etc. Of course we can describe <* by p <* q = pure const <*> p <*> q but this is also rather inefficient; why first building a result if you are going to throw it away anyway? My life would be simpler if the extensions would either be incorporated in the class Applicative, with default definitions, and were not defined at top level, or in a class Extend_Applicative. More in general I think it is preferred to place common patterns in classes with a default implementation, so they can be redefined instead of defining them at top level. 1) Does everyone agree with this observation, and if not what am I missing? 2) Can we change the module Applicative to reflect my view? I think it can be done without implying heavy changes to other modules. Doaitse

2 1

darcs patch: avoid import renaming errors in nhc98 (and 2 more)
by Malcolm.Wallace＠cs.york.ac.uk 06 Oct '08

06 Oct '08

Mon Oct 6 11:21:53 BST 2008 Malcolm.Wallace(a)cs.york.ac.uk * avoid import renaming errors in nhc98 Mon Oct 6 11:22:48 BST 2008 Malcolm.Wallace(a)cs.york.ac.uk * fix import of Control.Exception for nhc98 Mon Oct 6 11:23:29 BST 2008 Malcolm.Wallace(a)cs.york.ac.uk * in cabal file, avoid -package syb when building with nhc98

1 0

Data.Foldable documentation
by Stephan Friedrichs 04 Oct '08

04 Oct '08

Hello, I've got a suggestion for the documentation of the Data.Foldable module. The documentation [1] does not say anything about the order in which the elements are folded. But as far as I understand, the order in which the elements are traversed (i. e. the result of Data.Foldable.toList) has to bee deterministic. The documentation of the Foldable class IMHO should provide a clear statement about that. Example: I implemented a heap that internally uses a tree of elements. It uses a tree to store the elements, but two heaps might be equal (contain the same elements) and still be represented by different trees. Then instance Foldable (Heap p) where foldMap _ Empty = mempty foldMap f (Tree _ x l r) = foldMap f l `mappend` f x `mappend` foldMap f r is a bug which is not indicated by the documentation. Thanks in advance Stephan [1] using ghc-6.8.3 -- Früher hieß es ja: Ich denke, also bin ich. Heute weiß man: Es geht auch so. - Dieter Nuhr

3 2

HackageDB bug in exposed modules
by Alfonso Acosta 03 Oct '08

03 Oct '08

Hi, I just uploaded a library to hackagedb: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe Everything went smoothly, but the webpage shows certain hidden modules (other-modules section in the cabal description) as exposed. Am I missing something or is this a bug in HackageDB? Best regards, Alfonso Acosta

3 8

Map / Set folding API changes
by Scott Dillard 02 Oct '08

02 Oct '08

Regarding this thread : http://www.haskell.org/pipermail/libraries/2008-September/010653.html and this ticket : http://hackage.haskell.org/trac/ghc/ticket/2580 I've attached a patch (to trac) which expands on Evan's changes and propagates them to IntSet and IntMap. Some (possibly controversial) changes of note : * Added foldr and foldl functions for the map types. This is redundant, but so is much of the interface. The argument to foldlWithKey has a strange type, (a -> key -> value -> a), that does not place nice with flip and const. So I think its convenient to have foldl as well, and since we've got that why not throw foldr in too. * Specialized default implementations of foldl and foldr for Foldable class. This is perhaps better than exporting then from the map libraries. Data.Sequence does it this way, but the map libraries do not. If the API clutter is found to be unbearable then perhaps a major cleanup is in order, hiding all folds in the map/set modules and exporting them via Foldable. Questions remaining : Strict versions? I'm happy to add them. The only question is if it (further) clutters the API. As mentioned, the type of foldlWithKey is strange. It didn't dawn on me until I went to define foldl in terms of foldlWithKey. Perhaps change it to (a -> (k,v) -> a) ? This goes against the established (and IMO unfortunate) convention that all the "WithKey" functions pass the key as an additional argument, instead of tupling it with the value. Scott

1 0

The base library and GHC 6.10
by Ian Lynagh 30 Sep '08

30 Sep '08

Hi all, We're trying to decide what to do with the base library for GHC 6.10, in terms of how much of it should be broken up into separate packages. Since the recent proposal about this, we may be rethinking what we want to do, and we would welcome your opinions. First, the motivation for splitting base up: It becomes possible to separately upgrade the parts, and makes it easier for different people to maintain different parts. It makes it easier to see what the hierarchy is, and to restructure the hierarchy, and work towards more of the code being shared between different Haskell implementations. Plus it means that people can't re-tangle the logically separate components, which is all too easy to do when you just have one huge package. It also means that packages are clearer about what they depend on. One possibility, which would be really cool, is to separate all the IO modules from the non-IO modules; between that and looking at the extensions used (e.g. TH and FFI) it would then be clear whether or not a library could do any IO. Of course, the Prelude is a hurdle for this goal. Also, GHC's current plan for the base library: http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Planforlibraries essentially means forking base (as nhc98 would continue to use base in a darcs repo, while GHC would use it from a git repo, and there are no plans for any merging between these repos). Therefore any code that is to be shared between the implementations needs to not be in base, so from that point of view it would be good to pull out as much as possible. The main argument /against/ splitting base up is that at some point the dependencies of packages need to be updated to reflect the changes. However, GHC 6.10 will come with a base version 3, as well as the new base version 4, so the transition should be much smoother than the base 2 -> base 3 transition. Now, on with the proposed splitting. In the below, LoC stands for "Lines of Code". First the easy bit: The Data.Generics hierarchy is going to have a separate maintainer, and I think that everyone is agreed that it should be pulled out into an "syb package". I'll treat this as not part of base from here on. The only thing still being debated here is whether the Data class itself should remain in base or not. Some people believe that it should remain in base, as it is desirable to have Data instances for as many types as possible, and because there is a resistance among library writers against adding dependencies. The counter argument is that there are many other classes that the same is true of (e.g. uniplate, syb-with-class, binary), and it does not scale to put all of these classes into base. Also, by requiring a dep to be added even for the classes that have historically been included in base, adding dependencies for the sake of providing instances may become more socially acceptable. Now, on with the splitting. We have System.Console.GetOpt (129 LoC, 1 module) This doesn't really fit in with anything else in base, so the proposal is to split it off into its own getopt package. I don't think there is much objection to this one. Next we have the Control.Monad.ST Data.STRef (120 LoC, 6 modules) hierarchies. The proposal is to put these into an st package. The low-level implementation is still in base (69 LoC of in the GHC.ST and GHC.STRef), so to some extent this is a false separation. On the other hand, nhc98 doesn't support ST, so splitting this package off gets us closer to all implementations exposing the same modules from base. Then we have Control.Concurrent (490 LoC, 6 modules) hierarchy, along with System.Timeout (39 LoC) Data.Unique (32 LoC) (those modules depend on Control.Concurrent.*). The proposal is to put these into concurrent, timout and unique packages respectively. Again, this is a false separation, with 698 LoC left behind in GHC.Conc; at some time we'd hope that this could either be moved down to ghc-prim, or make a new ghc-concurrent package for it, depending on how the dependencies work out. Again, nhc doesn't support concurrent or its dependencies, so this gets us closer to a consistent base interface. Splitting off the above 5 packages would leave 106 modules and 16621 LoC in base. About 5% of the LoC, and 12.5% of the modules, would be in the new packages. Thanks Ian

16 65