- Libraries - Haskell.org

RE: Could this be added to Data?
by Simon Marlow 17 Jan '05

17 Jan '05

On 17 January 2005 14:16, Ross Paterson wrote: > On Mon, Jan 17, 2005 at 11:10:13AM -0000, Simon Marlow wrote: >> Ok, done. I've added a version of the library I had lying around >> which has fmapM_ in addition to fmapM, but it doesn't have any more >> instances than those in yours. > > Since Functor and Monad are defined in Control.Monad, shouldn't this > be there or somewhere else under Control? Or maybe there should be a Data.Functor? I don't really mind - any other opinions? Cheers, Simon

1 0

RE: Could this be added to Data?
by Simon Marlow 17 Jan '05

17 Jan '05

On 16 January 2005 06:26, John Meacham wrote: > Could someone with CVS write access add this to Data? I brought it up > before and there wern't any objections and several people responded > saying they have implemented the exact same module (with the same > names) so it would seem to make sense to include it. > > There are probably some more instances that can be added from the rest > of the libraries. Ok, done. I've added a version of the library I had lying around which has fmapM_ in addition to fmapM, but it doesn't have any more instances than those in yours. Cheers, Simon

2 1

Re: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Sven Panne 17 Jan '05

17 Jan '05

Simon Marlow wrote: > simonmar 2005/01/13 02:37:39 PST > > Modified files: > libraries/base package.conf.in > libraries/base/Data FiniteMap.hs Set.hs > Added files: > libraries/base/Data IntMap.hs IntSet.hs Map.hs > Log: > Add Data.Map, Data.Set, Data.IntMap and Data.IntSet from Daan Leijen's > DData library, with some modifications by JP Bernardy and others on > the libraries(a)haskell.org list. Minor changes by me to remove the > last references to DData, and add a DEPRECATED copy of the old > Data.Set interface to the new Data.Set. > > Data.FiniteMap is now DEPRECATED. > > Revision Changes Path > 1.11 +3 -0 fptools/libraries/base/package.conf.in > 1.20 +5 -1 fptools/libraries/base/Data/FiniteMap.hs > 1.8 +1096 -69 fptools/libraries/base/Data/Set.hs I must admit that I didn't follow the data structure discussion in every detail, but I find something confusing: In Data.FiniteMap.addListToFM_C, the combining function gets the old value as the 1st argument and the new value as the 2nd one. In Data.Map.insertWithKey (and friends), this seems to be the other way round, which is undocumented and *very* confusing when trying to port things from FiniteMap to Map. Is there a deep reason for this? Cheers, S.

3 3

RE: Codec 1.0
by Simon Marlow 16 Jan '05

16 Jan '05

On 12 January 2005 19:45, Dominic Steinitz wrote: > Simon Marlow wrote: >> What's a LargeWord? >> > For example, the keys for for encryption algorithms are words of 128, > 192, 256 bits. They are composed from smaller words. > > type Word128 = LargeKey Word64 Word64 > type Word192 = LargeKey Word64 Word128 > type Word256 = LargeKey Word64 Word192 Data.LargeWord seems reasonable, then. We probably don't want these in Data.Word. Do they support the full range of operations and instances? Cheers, Simon

2 1

Could this be added to Data?
by John Meacham 16 Jan '05

16 Jan '05

Could someone with CVS write access add this to Data? I brought it up before and there wern't any objections and several people responded saying they have implemented the exact same module (with the same names) so it would seem to make sense to include it. There are probably some more instances that can be added from the rest of the libraries. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

cabal posix build-depends issue
by Isaac Jones 15 Jan '05

15 Jan '05

Greetings. I have a bit of a problem with Cabal's need to build-depend on posix. I'm building cabal with itself, and I think this is what's happening: If it depends on posix, on a non-posix system, the user will get an error because the posix package doesn't exist. If it doesn't depend on posix on a posix-based system, then ghc won't get the -package posix flag, and so cabal will fail to link. On the other hand, "depends" in the cabal sense is meant to be a static value; not dependent on what kind of system you are using... it's kinda funny to say "if you're on a posix system, then cabal depends on posix." Cabal doesn't _really_ depend on POSIX... it only does in its Compat libraries, and we could get rid of all the POSIX code. I think another ugly workaround is to have cabal depend on "util" or something, since that package depends on posix on a posix system, and presumably it doesn't depend on posix on a non-posix system. Any ideas? Should we just delete the Posix code in cabal? peace, isaac

1 0

DData modules
by Ross Paterson 14 Jan '05

14 Jan '05

On Thu, Jan 13, 2005 at 02:37:39AM -0800, Simon Marlow wrote: > simonmar 2005/01/13 02:37:39 PST > > Modified files: > libraries/base package.conf.in > libraries/base/Data FiniteMap.hs Set.hs > Added files: > libraries/base/Data IntMap.hs IntSet.hs Map.hs > Log: > Add Data.Map, Data.Set, Data.IntMap and Data.IntSet from Daan Leijen's > DData library, with some modifications by JP Bernardy and others on > the libraries(a)haskell.org list. Minor changes by me to remove the > last references to DData, and add a DEPRECATED copy of the old > Data.Set interface to the new Data.Set. Int{Map,Set} use the type Word, but I think it was decided a while ago that this type shouldn't be standard. Should that be reconsidered? Also, these modules import Data.Monoid, which contains the non-H98 instance Monoid (a -> a), making it (and these) non-portable. One way out would be to replace that instance in Data.Monoid with one for data Endo a = Endo { runEndo :: a -> a }

4 5

RE: haddock library?
by Simon Marlow 14 Jan '05

14 Jan '05

On 14 January 2005 05:15, John Meacham wrote: > I was thinking it would be useful if parts of haddock could be made > into a library. mainly the parsing bits of it. There are a lot of > useful little documentation aware utilities that can be written, and > the haddock command itself can be simplified. By all means... a good first step would be to separate out the front end parts of Haddock into a Cabal package. The parser is derived from the Haskell 98 parser in Language.Haskell.Parser - it would be nice to replace this with a (parameterised) version of the Haddock parser to reduce duplication, but that's a fair bit of work. I'd put the Haddock front end in Language.Haskell.Haddock, perhaps. Cheers, Simon

1 0

RE: haddock library?
by Simon Marlow 14 Jan '05

14 Jan '05

On 14 January 2005 09:33, Lemmih wrote: > I've modified Haddock so it can dump the interfaces it has parsed (I > simple made Interface an instance of Binary with some TH code). The > Interface contains the parsed Haskell code plus documentation and this > serves me well since I only intend to create tools like a graphical > browser, :doc in GHCi and @doc in lambdabot. > I've had some setbacks while hacking on the browser (named wxHaddock > in lack better) and the lambdabot module but I'll probably finish both > when I get some more time on my hands. Sounds very cool! I imagine the dumped interfaces are going to be pretty large, though - and I'm pretty sure you don't need the whole of the Interface type. Cheers, Simon

1 0

haddock library?
by John Meacham 14 Jan '05

14 Jan '05

I was thinking it would be useful if parts of haddock could be made into a library. mainly the parsing bits of it. There are a lot of useful little documentation aware utilities that can be written, and the haddock command itself can be simplified. There are several haskell documentation tools out there and it would be advantagous if they could use the same in-code syntax but just have different back ends. other things someone might want to do with the haddock parser, but fall outside the haddock tools scope: - A version which knows how to get type signatures from ghc even if they are not in the source. - A command line utility which searches an optimized index built from the haskell modules and their haddock annotations. - Various other web presentations of the data. there is a lot of room for experimentation. - A graphical browser which generates graphs of code dependence and lets you look at the documentation for any function. - integration with a haskell debugger. I was thinking it could go into the Text hierarchy somewhere. John -- John Meacham - ⑆repetae.net⑆john⑈

2 1