- Libraries - Haskell.org

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

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

Cabal hooks
by Krasimir Angelov 13 Jan '05

13 Jan '05

Hello, Guys I am trying to cabalize HSQL. There is a simple ./configure script which performs some simple checks. Now I would like to perform these checks from Setup.lhs using Cabal hooks. The hooks API looks a little bit strange for me. The preConf hooks returns (Maybe PackageDescription) which after that is merged with the basic description. The Setup.buildinfo file contains only the hooked description instead of merged one. The parser requires to have package name and version, in order to properly parse the description. I need to return the right name and version from preConf hook to satisfy this restriction. I can't do this without re-reading the original description from Setup.description. Isn't it simpler to change the hooks type to something like: PackageDescription -> IO PackageDescription where the argument is the original description and the result is the possible updated one? This avoids the need of merging and simplifies the library code. Cheers, Krasimir

4 8

RE: Codec 1.0
by Simon Marlow 12 Jan '05

12 Jan '05

On 11 January 2005 20:59, Dominic Steinitz wrote: > As an interim proposal, how about I put > > Data.LargeWord What's a LargeWord? > Data.Digest.MD5 > Data.Digest.SHA-1 That will have to be SHA1 or SHA_1. > Codec.Encryption.RSA > Codec.Encryption.RSA.EMEOAEP > Codec.Encryption.RSA.MGF > Codec.Encryption.RSA.NumberTheory > Codec.Encryption.DES > Codec.Encryption.AES > Codec.Encryption.Blowfish > Codec.Encryption.Modes > Codec.Encryption.Padding > Codec.Encryption.PKCS8 > Codec.Encryption.X509 > Codec.ASN1 > Codec.ASN1.BER > Codec.ASN1.TLV > Codec.Utils > > into a package called Crypto? Looks fine! Cheers, Simon

2 1