January 2005 - Libraries

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 16 Jan '05

16 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 15 Jan '05

15 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

RE: DData modules
by Simon Marlow 13 Jan '05

13 Jan '05

On 13 January 2005 12:39, Ross Paterson wrote: > 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? I don't see a problem with Word given that we have Int. However this tends to turn into a religious argument so that's all I'm going to say on it :-) Cheers, Simon

2 1

package description fields
by Ross Paterson 13 Jan '05

13 Jan '05

Is there any difference between Homepage and Package-Url? Can one of them be removed? How about moving Build-Depends to the package level (and maybe calling it Depends)? Is it sufficient to put License: BSD3 in the package description? Or should License-File be mandatory, and License just an optional hint? (Some people seem to think they should put a copy of the entire licence in each source file. :-) It doesn't seem to be very useful to have both a library and executables that use it in the same package (at least with the meaning implemented for GHC). One has to list all the library modules again under each executable.

2 2