February 2005 - Libraries

Typeable SockAddr
by Peter Simons 24 Feb '05

24 Feb '05

I was wondering: Is there any reason why SockAddr (and other types in Network.*) are not instances of Typeable?

2 1

How to implement Data.Map.insertList*?
by Mirko Rahn 24 Feb '05

24 Feb '05

The old FiniteMap module contains the addListToFM* functions that are missing in Data.Map. But how to implement it? First answer: insertList_foldl :: Ord k => [(k,a)] -> Map.Map k a -> Map.Map k a insertList_foldl = flip (foldl ins) where fluc = flip . uncurry ins = fluc Map.insert Second answer: insertList_union :: Ord k => [(k,a)] -> Map.Map k a -> Map.Map k a insertList_union kas = Map.union (Map.fromList kas) Situation and Problem: We already have a map of size n and want to insert a list with m elements. Then we look at the documentation and one gets: * For the first answer we do need O(sum_{i=0}^{m-1}log(n+i)) = O(log((m+n)!/n!)) operations. * For the sencond answer we do need O(m*log(m))+O(n+m) = O(m*log(m)+n+m) operations. These terms are hard to compare but a plot shows that insertList_foldl should be faster than insertList_union. But a testprogram shows that insertList_union is faster (and needs less memory) whatever the sizes of n and m are. So my questions are: Why are the insertList* functions missing? How would the library implementors implement insertList* and why? thanks, -- -- Mirko Rahn -- Tel +49-721 608 7504 -- --- http://liinwww.ira.uka.de/~rahn/ ---

4 5

RE: required fields in Cabal
by Simon Marlow 23 Feb '05

23 Feb '05

On 22 February 2005 13:17, Krasimir Angelov wrote: > On Mon, 21 Feb 2005 17:56:08 -0800, Isaac Jones > <ijones(a)syntaxpolice.org> wrote: >> * What any good package should have: >> package (name and version) :: PackageIdentifier, >> license :: License, >> -- OR? >> licenseFile :: FilePath, >> copyright :: String, >> maintainer :: String, >> synopsis :: String, > > The good package should have these fields but they aren't required if > you only want to build some code with Cabal. This will be the typical > case with VSHaskell. The developer will use Cabal in order to build > his/her projects but may never fill these fields. These fields are > important when the developer decide to distribute the package. I think > that Cabal should check only for "package" field, but Hackage should > check for all fields. Krasimir's right, I'd forgotten about this. Cabal is going to be used not just for distributing libraries & tools, but also just as a simple build system for local code (and why not?), and as the main build system for Visual Haskell. In which case there's no need to have the license, copyright, maintainer or synopsis fields - since you're not necessarily giving the code to anyone. Perhaps if you attempt to do './setup sdist' then it should complain if these fields are missing, but otherwise omitting them shouldn't be fatal. Cheers, Simon

2 1

Monoid library
by Iavor Diatchki 22 Feb '05

22 Feb '05

Hello, For the purposes of my monad library I wrote a small monoid library that I am attaching to this mail. Instead of using overloading, it makes the monoid structure explicit. In this way we can have both additive and multiplicative monoids on the same type, and for my library it removes the 'Monoid' constraints that were all over the place (the same happens in 'mtl'). The version that I post here coexists with the overloaded approach, but I am not sure that both of them are needed. If people think that this way of doing monoids is useful, perhaps we should update the Data.Monoid. -Iavor

1 0

ANN: HAppS -- Haskell Application Server v 0.2
by S. Alexander Jacobson 22 Feb '05

22 Feb '05

HAppS is a Haskell library for building Internet applications, featuring: * HAppS.ACID: Guarantee application integrity in the face of unplanned outages using this module's integrated write-ahead logging and checkpointing framework. * HAppS.DBMS: Do relational operations in Haskell (rather than SQL) on Haskell sets (outside the IO Monad). Define custom indices for your Haskell datatypes (e.g. geographic/geometric types). Use in combination with ACID for a robust relational DBMS customized for your application. * HAppS.Protocols: Expose your application using as an HTTP server and/or by recieving and sending SMTP. - License HAppS is released by HAppS.org under the terms of the GNU General Public License Version 2, a copy of which is enclosed with this package. - How do I get HAppS? More information is available at http://HAppS.org A tarball of HAppS is available at http://HAppS.org/HAppS/happs.tar.gz. HAppS is also available via darcs: darcs get http://happs.org/HAppS ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

required fields in Cabal
by Isaac Jones 22 Feb '05

22 Feb '05

Greetings. I want to have a very quick discussion about which fields are required in the Cabal. I intend to implement these in the little sanity checker, and they should be documented. If we have any time at all before GHC gets released, we don't have much so this can't be a very long discussion ;) BTW, Should we regularize the names of the fields at this late date? Sorry for not doing this earlier. We have libBuildInfo for libraries, but buildInfo for executables. We also have exeName. Does anything outside of cabal depend on these names (yet)?[1] * What's required: Library: exposedModules is required. If it's empty, and BuildInfo is non-empty, this is an error. Executable: exeName and modulePath are required. If exeName is empty, this is a parse error. All buildInfo fields are optional. Everything in BuildInfo is optional. So that leaves us with the PackageDescription type itself. Let's talk about what I think is absoluteluy required for building, and then the fields I think should be there in any useful package that someone wants someone else to use. Are there any fields that any of the layred tools absolutely require? (Hackage, etc)? * What's needed for building I won't swear to it, but I think all you generally need to build a library is: package :: PackageIdentifier, -- From the library field: exposedModules :: [String], and an executable: package :: PackageIdentifier, -- from the executables field: exeName :: String, modulePath :: FilePath, * What any good package should have: package (name and version) :: PackageIdentifier, license :: License, -- OR? licenseFile :: FilePath, copyright :: String, maintainer :: String, synopsis :: String, Personally, I think it should be an error if any of these fields are missing. I think I'll go implement that now. Stop me if you object. peace, isaac [1] As a reminder, here are the the relevant types. data PackageDescription = PackageDescription { -- the following are required by all packages: package :: PackageIdentifier, license :: License, licenseFile :: FilePath, copyright :: String, maintainer :: String, author :: String, stability :: String, testedWith :: [(CompilerFlavor,VersionRange)], homepage :: String, pkgUrl :: String, synopsis :: String, description :: String, category :: String, buildDepends :: [Dependency], -- components library :: Maybe Library, executables :: [Executable] } data Library = Library { exposedModules :: [String], libBuildInfo :: BuildInfo } data Executable = Executable { exeName :: String, modulePath :: FilePath, buildInfo :: BuildInfo } data BuildInfo = BuildInfo { buildable :: Bool, -- ^ component is buildable here ccOptions :: [String], -- ^ options for C compiler ldOptions :: [String], -- ^ options for linker frameworks :: [String], cSources :: [FilePath], hsSourceDir :: FilePath, otherModules :: [String], extensions :: [Extension], extraLibs :: [String], extraLibDirs :: [String], includeDirs :: [FilePath], includes :: [FilePath], options :: [(CompilerFlavor,[String])] }

3 5

RE: Language.Haskell.Parser and layout rules
by Simon Marlow 22 Feb '05

22 Feb '05

On 22 February 2005 11:14, Malcolm Wallace wrote: >>> A B C D >>> ghc yes no no yes >>> hugs yes no no no >>> nhc98 yes yes no yes >>> Language.Haskell.Parser.parseModule no yes yes no >>> report no no no no > > ... but I beg to differ with the row for the "report". Looking > carefully at code examples A and B, notice the extra single space > indentation on the second line: I was assuming that was a typo :-) Simon

2 1

RE: Language.Haskell.Parser and layout rules
by Simon Marlow 22 Feb '05

22 Feb '05

On 18 February 2005 16:31, Mirko Rahn wrote: >> The Report (section 9.3, especially notes 1 and 2) says "A nested >> context must be further indented than the enclosing context", ... > > Okay, I understand, but the behavoir of hugs vs ghc vs > Language.Haskell.Parser is still strange: The sniplets > > ** A: > g xs = do ys <- workM xs > if null ys then return [] else do > zs <- workM ys > return zs > > ** B: > g xs = do ys <- workM xs > if null ys then return [] else do > zs <- workM ys > return zs > > ** C: > f xs = case xs of > y:ys -> case ys of > z:zs -> zs > > ** D: > f x = case x of > False -> do > { return x; } > > are accepted by > A B C D > ghc yes no no yes > hugs yes no no no > Language.Haskell.Parser.parseModule no yes yes no > report no no no no Hugs is probably the most correct here. A is intentionally parsed by Hugs and GHC. D is a known bug in GHC. It looks like Language.Haskell.Parser may have bugs in this area. Interestingly, Haddock is better than GHC, giving the same results as Hugs. Haddock's parser is based on Language.Haskell.Parser, so it looks like a bug has been introduced in Language.Haskell.Parser at some point. Cheers, Simon

3 2

RE: ANN: Cabal 0.5 (GHC 6.4 release candidate)
by Simon Marlow 22 Feb '05

22 Feb '05

On 22 February 2005 08:24, Jens Petersen wrote: > Yes, as in whether install dir is made under /usr/lib or > /usr/lib/ghc-<version>/ or whatever. So really this is a > request for a "--libdir" option to setup? In some cases > --prefix may be sufficient, but not if there is both > an executable and libraries in a package for example. --libdir is a good idea. >>> Personally I would like to see ghc libraries at least installed >>> under ghc's libdir since their ABI depends on the version of ghc >>> they are built with, ie typically under $libdir/ghc-$ghc_version/ >>> rather than $libdir. >> >> You mean by default, without using the --prefix flag? That seems >> pretty reasonable. > > Yep. Actually if this were the default, I probably wouldn't > need --libdir much at all. :-) I'm not keen for libraries to install in ghc's libdir by default. I'd like to keep GHC's choice of libdir and its layout private to GHC, I don't see the need for other installers to depend on it. By all means make the default package libdir something like $(prefix)/lib/$(package)-$(version)-ghc$(ghcversion). Cheers, Simon

2 1

RE: required fields in Cabal
by Simon Marlow 22 Feb '05

22 Feb '05

On 22 February 2005 01:56, Isaac Jones wrote: > BTW, Should we regularize the names of the fields at this late date? > Sorry for not doing this earlier. We have libBuildInfo for libraries, > but buildInfo for executables. We also have exeName. Does anything > outside of cabal depend on these names (yet)?[1] VS is using them, I recently updated our VS code to match the current Cabal. I'm not too worried about the names of fields right now, since I think things will have to change in the future anyway when we sort out the relationship between libraries & executables. Change buildInfo to exeBuildInfo if you like, and maybe modulePath to exeMainPath? Cheers, Simon

1 0