- Libraries - Haskell.org

Announce: Cabal 0.1 (Library Infrastructure Project)
by Isaac Jones 02 Aug '04

02 Aug '04

Much thanks to all who've made this possible :) The Haskell Cabal The Common Architecture for Building Applications and Libraries. DOWNLOAD: The Haskell Cabal has reached pre-release stage, with a 0.1 version The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here: http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items here: http://sourceforge.net/tracker/?func=add&group_id=44807&atid=440922 Or email Isaac Jones: ijones(a)syntaxpolice.org ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/

2 2

dashes in cabal package names
by Isaac Jones 31 Jul '04

31 Jul '04

Does anyone have any objection to allowing dashes within Cabal pacakge names? This might impact the parser for HC-PKG, but that's the way it is now, and seems to make the most sense. I think the only change to HC-PKG would be to use a non-dash separator between the package and version; we can decide exactly how to do that at a later time. peace, isaac

1 0

RE: hierarchical libraries documentation index
by Simon Marlow 30 Jul '04

30 Jul '04

On 29 July 2004 15:40, Krasimir Angelov wrote: > --- Simon Marlow <simonmar(a)microsoft.com> wrote: >> If you find it a pain to navigate the combined >> contents page, then I think the solution is not to >> split it up, but to make it easier to navigate (a >> bit of dynamic HTML goes a long way...). > > I also think that navaigation through the Contents > page is painful. It could be useful to use dynamic > expandable tree using DHTML. > Another solution is to use specialized browsers > for Html Help. Under Windows the right solution is to > use Microsoft Html Help and under Linux there is > DevHelp browser from GNOME. I already have implemented > MSHelp 1.2 and MSHelp 2.0 support for Haddock. I > wouldn't so hard to add DevHelp. > The best way is to combine both solutions. I can > play a bit with the Contents page. Haddock in CVS has support for expandable/collabsable blobs with a +/- button, if that's any help. (it's not quite ready for general use; there are some browser incompatibilities for one thing.) I'd planned to experiment with using it for the module tree on the contents page. Cheers, Simon

2 1

toMaybe [Was: Prelude function suggestions]
by Henning Thielemann 30 Jul '04

30 Jul '04

On Thu, 29 Jul 2004, Arie Peterson wrote: > Henning Thielemann wrote: > > Or say you want to implement a function > > > > f :: Set (Maybe a) -> Maybe (Set a) > > > > where the result is Nothing if any element of the Set is Nothing, and Just > > the set containing the Just values otherwise: > > > > f s = toMaybe (not (Nothing `elementOf` s)) (mapSet fromJust s) > > You might write f as > > f = fromList . sequence . toList > > (where sequence is from Control.Monad) if there are 'toList' and > 'fromList' functions, or maybe adapt 'sequence' to work with sets (or even > an appropriate generalisation of lists and sets). It was recently pointed out that Sets can't be monads, http://www.haskell.org/pipermail/haskell-cafe/2004-March/005995.html so 'sequence' can't be used immediately, but maybe some different generalization. What you propose works in principle, BUT since the Set structure must be rebuilt, an Ord context is necessary whereas my implementation doesn't need one. Regards, Henning

1 0

Re: Prelude function suggestions
by Henning Thielemann 30 Jul '04

30 Jul '04

On Thu, 29 Jul 2004, Tomasz Zielonka wrote: > On Thu, Jul 29, 2004 at 06:29:52PM +0200, Henning Thielemann wrote: > > Say, you have some stop condition that you want to use in connection with > > unfoldr: > > > > unfoldr (\n -> toMaybe (n<10) (n,n+1)) 0 > > How about using MonadPlus instance for Maybe? It seems a bit clearer to > me. > > unfoldr (\n -> guard (n<10) >> return (n,n+1)) 0 Ok, nice. Though then again I think about falling back to unfoldr (\n -> if n<10 then Just (n,n+1) else Nothing) 0 I just use toMaybe as common abbreviation. If no one needs it, forget it. :-)

1 0

Re: Prelude function suggestions
by Henning Thielemann 29 Jul '04

29 Jul '04

On Thu, 29 Jul 2004, ariep wrote: > > > {- | Compositional power of a function, > > i.e. apply the function n times to a value. -} > > nest :: Int -> (a -> a) -> a -> a > > nest 0 f x = x > > nest n f x = f (nest (n-1) f x) > > nest n f x = iterate f x !! n > > That might render 'nest' somewhat superfluous. What about: nest n f = foldl (.) id (replicate n f) :-) I'm aware of such transcriptions, but most commonly I use the partial application (nest n f) which can't be provided by them. If 'nest' (or maybe renamed to 'compPower') will be added, anyway, I think it should go where (.) is defined. > > {- | Split the list at the occurrences of a separator into sub-list. > > This is a generalization of 'words'. -} > > chop :: (a -> Bool) -> [a] -> [[a]] > > chop p s = > > let (l, s') = break p s > > in l : case s' of > > [] -> [] > > (_:rest) -> chop p rest > > I like 'chop'. It belongs in Data.List, I'd say. Nice that you like it. :-) Will the text processing functions like 'words' and 'lines' go to a module separate from Data.List in future? > > {- | Returns 'Just' if the precondition is fulfilled. -} > > toMaybe :: Bool -> a -> Maybe a > > toMaybe False _ = Nothing > > toMaybe True x = Just x > > Could you give an example to show what makes 'toMaybe' a particularly > useful function? Say, you have some stop condition that you want to use in connection with unfoldr: unfoldr (\n -> toMaybe (n<10) (n,n+1)) 0 Or say you want to implement a function f :: Set (Maybe a) -> Maybe (Set a) where the result is Nothing if any element of the Set is Nothing, and Just the set containing the Just values otherwise: f s = toMaybe (not (Nothing `elementOf` s)) (mapSet fromJust s)

3 2

RE: Prelude function suggestions
by Simon Marlow 29 Jul '04

29 Jul '04

How about: -- | Splits a list into components delimited by separators, where the -- predicate returns True for a separator element. The resulting -- components do not contain the separators. Two adjacent separators -- result in an empty component in the output. eg. -- -- @ -- > split (=='a') "aabbaca" -- ["","","bb","c",""] -- @ split :: (a -> Bool) -> [a] -> [[a]] split p s = case rest of [] -> [chunk] _:rest -> chunk : split p rest where (chunk, rest) = break p s -- | Like 'split', except that sequences of adjacent separators are -- treated as a single separator. eg. -- -- @ -- > tokens (=='a') "aabbaca" -- ["bb","c"] -- @ tokens :: (a -> Bool) -> [a] -> [[a]] tokens p = filter (not.null) . split p 'split' is the same as Python's split. There is already a precedent for using short names in the Data.List module so I think 'split' is the right choice, and 'tokens' is fairly descriptive. Then we have words = tokens isSpace which is quite nice. Unfortunately lines /= split (=='\n') because lines strips off blank lines at the end. So perhaps we do need the third version. Cheers, Simon

7 7

RE: hierarchical libraries documentation index
by Simon Marlow 29 Jul '04

29 Jul '04

On 29 July 2004 14:16, Martin Sjögren wrote: > I think it would be nice to have the docs split up per-package. I.e. > one page for haskell98, one for base, one for unix etc. Of course, > there could be a complete page of everything too, but I find it's a > pain to navigate it because it's so long... Are you talking about splitting up the contents, or the index? Up until the last release, both of these pages used to be per-package. But we found that this was bad because someone looking for a particular module didn't know which package to look in, and the package boundaries are kind of arbitrary. In the future, when an installation probably has lots of 3rd-party packages installed, each with their own documentation, we'll probably need to re-generate the contents and index page each time a new package is installed. If you find it a pain to navigate the combined contents page, then I think the solution is not to split it up, but to make it easier to navigate (a bit of dynamic HTML goes a long way...). Cheers, Simon

4 3

hierarchical libraries documentation index
by Ross Paterson 29 Jul '04

29 Jul '04

How about omitting the modules of the haskell98 package from the Haskell Hierarchical Libraries documentation index? They're not particularly hierarchical, and they're documented elsewhere. Having them in the doc index makes the docs look bad.

3 3

RE: hierarchical libraries documentation index
by Simon Marlow 29 Jul '04

29 Jul '04

On 29 July 2004 11:32, Ross Paterson wrote: > How about omitting the modules of the haskell98 package from the > Haskell Hierarchical Libraries documentation index? They're not > particularly hierarchical, and they're documented elsewhere. > Having them in the doc index makes the docs look bad. Ok by me. Simon

1 0