July 2004 - Libraries

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

RE: copyFile function in Haddock, VSHaskell & Cabal
by Simon Marlow 29 Jul '04

29 Jul '04

On 29 July 2004 08:19, Krasimir Angelov wrote: > I have found a bug in CVS Haddock. It uses the > following definition of copyFile function: > > copyFile f = do > s <- readFile (libdir ++ pathSeparator:f) > writeFile (odir ++ pathSeparator:f) s > > (See HaddockHtml.hs) > > This works well for text files but the function fails > when it is used to copy binary files under Windows. > Similar functions are used also in VSHaskell and > Cabal. I propose to add copyFile function to > System.Directory which will take care of binary files. > The function signature is simple: > > copyFile :: FilePath -> FilePath -> IO () > > In the attached file there are two implementations. > The first is a more portable but slower and the second > is GHC specific but is faster. We have a copyFile function in DirectoryExts (hslibs/lang). I've been meaning to move this over to System.Directory for some time. Your version looks fine - please go ahead! Cheers, Simon

1 0