- Libraries - Haskell.org

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

ANN: Cabal 0.5 (GHC 6.4 release candidate)
by Isaac Jones 22 Feb '05

22 Feb '05

This is a release-candidate for 0.6, which will be in GHC 6.4. http://www.haskell.org/cabal/download.html The Haskell Cabal The Common Architecture for Building Applications and Libraries. http://www.haskell.org/cabal IMPORTANT INFORMATION: See both the README file and the changelog for important interface changes. DOWNLOAD: The Haskell Cabal has reached pre-release stage. The community should use this release to evaluate the interfaces and explore the concepts of these tools. Download the Cabal here (source and debian versions available): http://www.haskell.org/cabal/download.html BUGS: Please report bugs and wish-list items to libraries(a)haskell.org and Isaac Jones: ijones(a)syntaxpolice.org. ABOUT: The Haskell Cabal is meant to be a part of a larger infrastructure for distributing, organizing, and cataloging Haskell Libraries and Tools. It is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community. Specifically, the Cabal describes what a Haskell package is, how these packages interact with the language, and what Haskell implementations must to do to support packages. The Cabal also specifies some infrastructure (code) that makes it easy for tool authors to build and distribute conforming packages. The Cabal is only one contribution to the larger goal. In particular, the Cabal says nothing about more global issues such as how authors decide where in the module name space their library should live; how users can find a package they want; how orphan packages find new owners; and so on. NOTES: You cannot currently execute the setup scripts with "./Setup.lhs" since Cabal Hugs support isn't ready-for-prime-time. You can compile it with ghc thusly: "ghc -package Cabal Setup.lhs -o setup" and then use the "setup" executable after that. This release is meant to provide the community with concrete information about how the interfaces are shaping up. This release does NOT fix the interfaces, we can't promise not to break anything that relies on these interfaces. We hope that Haskell authors will try to package their software using these tools, and let us know where they fall short. MORE INFORMATION: Please see the web site for the source code, interfaces, and especially the proposal, which will serve as documentation for this release: http://www.haskell.org/cabal/

3 4

ANN: Hacanon 0.1
by Lemmih 21 Feb '05

21 Feb '05

What is Hacanon? Hacanon is a Template Haskell library which automates the process of binding Haskell to libraries written in C++. It's designed to capture common patterns and allow the programmer to specify the desired behaviour accordingly. Hacanon is capable of generating a usable binding, without any interaction, to almost any piece of C++. This binding is of relatively high level, because Hacanon translates enumerations to Haskell data structures, has transparent callback support and overloads every function. Unfortunately, such a binding would, in most cases, be flawed. Is 'int*' an array, variable which holds a second result or something third? Here Hacanon provides a data interface scheme (aka DIS) system which allows the programmer to concisely describe how an argument should be handled. DISs can be derived from other DISs because they're nothing more than data structures. This gives rise to increased code reuse and minimizes the burden on the programmer. These DISs can be used in the appliance system where the programmer can guard on function name (via regex), argument type and argument number. Some of the features sound familiar. Is Hacanon related to GreenCard or HDirect? I've borrowed the DIS concept from GreenCard and directional arguments from HDirect. I would like to think I've taken the best of both worlds and added some innovation in form of automation. Dependencies: * Recent version of GHC. Tested with ghc-6.4.20050209 and ghc-6.4.20050219. http://www.haskell.org/ghc * HaXml 1.12. http://www.cs.york.ac.uk/fp/HaXml/ * GCCXML from CVS hacked to include template information. Hack is distributed with Hacanon. Author and availability: Hacanon is written by David Himmelstrup and published under a MIT-style license. Darcs repository: http://www.scannedinavian.org/repos/hacanon/ -- Friendly, Lemmih

2 2

Related work on timezones/calendars/etc
by Graham Klyne 21 Feb '05

21 Feb '05

Very loosely apropos the time library discussion, there's some related activity concerning timezones. I cite below a particular message [1] from Dan Connolly (W3C), because he's very good at placing links to other relevant resources in his messages... [1] http://lists.w3.org/Archives/Public/www-rdf-calendar/2005Feb/0009.html #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0