- Libraries - Haskell.org

Existing libraries and tools
by Alastair Reid 11 Jun '03

11 Jun '03

Whilst we're thinking about library infrastructure, binary packages, orphaned libraries, etc. I just found what I think is the most comprehensive list of Haskell libraries and tools in existence. This list is basically all the Haskell-related FreeBSD ports for: http://www.freshports.org/haskell/ It's a very impressive list - far more comprehensive than for any other platform. A very useful feature is that each entry includes links to the homepages of libraries and tools so it's easy to find a source package if you don't happen to use FreeBSD. I realized how useful this list was while creating a table of which libraries are available on which packaging systems. The table is near the bottom of: http://haskell.org/hawiki/LibrariesAndTools Apologies for any errors. Please make any necessary corrections directly... -- Alastair Reid

1 0

Re: openFile and text mode vs. binary mode
by Graham Klyne 10 Jun '03

10 Jun '03

At 10:33 10/06/03 +0100, Simon Marlow wrote: > hSetBinaryMode :: Handle -> Bool -> IO () What (of any real value) is lost by fixing the IO mode at the point of obtaining the handle? I'm guessing that having an option to change the mode later may at best create additional work, and maybe even create inconsistencies in behaviours on different systems. #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0

Haskell library infrastructure coordinator
by Simon Peyton-Jones 10 Jun '03

10 Jun '03

Gentle Haskell librarians It is common ground that "better libraries" is perhaps the single thing that would boost Haskell most; and that the best way to better libraries is the bazaar model, not the cathedral. There has therefore been quite a lot of discussion recently on this list about a) What does Joe Haskell Programmer have to do to build and distribute a Haskell library, so that it is easy for users to install and use? b) What infrastructure exists to ease Joe's task, especially building distributions, perhaps for for multiple platforms and multiple Haskell compilers? Lots of suggestions emerged, and lots of people have knowledge and willingness to help. What we need, though, is someone to coordinate this group. It's difficult to reach technical agreement in a distributed group without one person who is willing to * Make proposals * Moderate discussion * Be open minded; not impose his/her own views * Drive discussion towards taking decisions * Document the consensus * Probably implement some core infrastructure, or at least coordinate the efforts of others to do so * Restrain ambition: something modest that works is better than something aspirational that doesn't Simon Marlow and I would like to propose Isaac Jones for this coordination role. He is knowledgeable, open minded, and not connected with any particular Haskell implementation. Most important of all, he is willing! (Very much not to be taken for granted -- it's a big job.) You should know him from his postings to this list. Is that acceptable to everyone? Does anyone want to propose anyone else (check they are willing first), or themselves? A huge thank-you to Isaac. Haskell only works because people contribute to it. Simon and Simon

9 20

ANNOUNCE: HaXml-1.09
by Malcolm Wallace 09 Jun '03

09 Jun '03

HaXml-1.09 ---------- We announce a refresh release of the HaXml toolkit for manipulating XML documents from Haskell. There are no major new features here, just a bunch of bugfixes, and a few incremental changes in the API. * ghc-6.0 is supported. * hmake is no longer required to build HaXml, provided you have ghc --make. * A new combinator 'path' has been added to Text.XML.HaXml.Combinators, allowing queries to be expressed in the style of XPath. * Some of the signatures in Text.XML.HaXml.Xml2Haskell have changed, in particular, there are new functions readXml and showXml that convert to/from Strings, hGetXml and hPutXml that use file Handles, and the old functions that use filenames are renamed to fReadXml and fWriteXml. * DtdToHaskell previously generated incorrect code for reading an XML element given the following DTD fragment: <!ELEMENT foo (a,b)+ > * The parser had a fault when reading conditional sections nested inside an IGNORE section in a DTD. * In Text.XML.HaXml.Html.Generate, all functions now generate HTML tags in lower-case rather than upper-case, to conform to the XHTML standard. * DtdToHaskell now accepts NOTATION types for attributes. They are treated just like enumeration types. * If you give an output filename as a command-line argument to DtdToHaskell, it now uses the filename as the basis for the generated module name. * Fixed a configuration bug on the Cygwin platform with ghc-5.04.x. * make install now places the executables (DtdToHaskell, Xtract, Validate, MkOneOf, Canonicalise) into the directory specified by ./configure --prefix=... Regards, Malcolm

2 3

RE: monad transformer library
by Simon Peyton-Jones 09 Jun '03

09 Jun '03

You do know that in GHC (though not Hugs) you can say newtype Foo = MkFoo Baz deriving( Monad, MyClass, This, That ) That is, deriving works for arbitrary classes for newtypes, just using the instance for the representation type. This greatly alleviates the pain you refer to. It's documented in the GHC user manual. Mind you, it's probably no help to you because we must support Hugs and nhc here S | -----Original Message----- | From: libraries-admin(a)haskell.org [mailto:libraries-admin@haskell.org] On Behalf Of Iavor Diatchki | Sent: 04 June 2003 21:16 | To: Iavor Diatchki | Cc: Ross Paterson; libraries(a)haskell.org | Subject: Re: monad transformer library | | hello, | | Iavor Diatchki wrote: | >> Use of type synonyms, like | >> | >> type Reader r = R.ReaderT r Identity | >> | >> is more economical, but will lead to more complex error messages. | > | > this is a good point and i will change that, unless anyone objects? | | i am having 2nd thoughts about that. using newtypes will require an | alwful lot of "fake" instances making the libarary about 2 times bigger. | i tried to make a few errors and the error messages did not seem much | worse with the "type" -- what happens is that "missing instances" are | reported for the Identity monad, rather than the "Reader" monad. | this seems reasonable as methods usually just search for the first layer | that implements a given "feature", until they hit the "base case". using | newtype changes the base case from Identity to Reader, which in some | case i think is perhaps more confusing. any thoughts? | | bye | iavor | | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

4 3

Italian-crafted Rolex - only $65 - $140!! Free SHIPPING ! !
by tony2003＠yahoo.ca 07 Jun '03

07 Jun '03

1 0

Food for thought: Numeric.Special
by Matthew Donadio 06 Jun '03

06 Jun '03

Hi all, I am currently working on a module where I need some "special" math functions (elliptic integrals and Jacobi elliptic functions). This got me thinking that there may be a place in the Numeric hierarchy for a Special branch. I think the only sane way to do this is with FFI, and I think the GNU Scientific Library (GSL) is the best target for this. Some people may have access to the IMSL or NAG libraries, but I doubt that most do. I also believe that GSL is available for all of the targets currently served by the various Haskell compilers, including Windows The best way to attack this is probably to have a module for each group of functions. So there would be Numeric.Special.Gamma, Numeric.Special.Zeta, etc. The Haskell names would match the GSL names minus the gsl_sf prefix. Most (all?) of the functions are pure, and basically accept doubles or ints as parameters and return a double. So, it's not a hard job, but there are a zillion functions. I am willing to (slowly) tackle the job since I already have it started. Thoughts? Comments? -- Matthew Donadio <m.p.donadio(a)ieee.org>

4 5

RE: monad transformer library
by Simon Peyton-Jones 06 Jun '03

06 Jun '03

| > That is, deriving works for arbitrary classes for newtypes, just using | > the instance | > for the representation type. This greatly alleviates the pain you refer | > to. It's documented in the GHC user manual. | | I recall that you came across a glitch with the specification of this | feature -- is that all sorted out now? Hmm. I've forgotten a glitch. I'm not aware of any problem though. S

1 0

decisions on building infrastructure
by Isaac Jones 06 Jun '03

06 Jun '03

Greetings, Most of the discussion about the "library infrastructure" has been about whether to start with a build system or a distribution system. The solution to that discussion, in my mind, is to come at it from both sides and meet in the middle. Peter Simons will be working on a proposal for distribution, and we'll be working together to integrate some kind of package / build / install / distribute mechanism. With that in mind, we need to make some decisions about what the build infrastructure will look like. To recap, I propose that we have 1) a "default" makefile system. Alastair Reid is working on one based on fptools' makefiles. We can provide a tool to generate a skeleton makefile system for new libraries. 2) an abstraction layer, perhaps like "distutils" for python combined with Debian's deiban/rules file which will allow us to build layered tools which will: - Make it so that 3rd party library authors don't _have_ to change their build system - Make it easier for packagers to make Debian / Redhat / FreeBSD packages, - Make it easier for 3rd parties to distribute their libraries on their home pages (probably in a source tarball) - Make it easier for end users to download, install, and keep up to date 3rd party libraries My proposal is on the wiki (see URL below). Does anyone have comments about the proposal? Does anyone think that something similar to what Python has is a bad idea? http://www.haskell.org/hawiki/LibraryInfrastructure peace, isaac

5 6

RE: install targets on package building infrastructure
by Simon Marlow 05 Jun '03

05 Jun '03

> While working with Jens Petersen to improve the redhat > packages for greencard, > we came across a problem in the standard install targets in makefiles. > > Normally, we want 'make install' to: > > build the library > install the library in /usr/lib/whatever (or similar place) > invoke ghc-pkg to tell ghc about the package > > When building a package binary though, we only want to do the > first two steps > and only perform the third step on the users machine. > > What's the preferred way of doing this? > (I figure this has already been solved for ghc and for some > non-haskell packages) You don't want to copy the way we do it for GHC (it's a hack). The right way is to do exactly what you described above: run ghc-pkg at install time. For that, you either need to generate package.conf at install-time too, with the correct paths in it, or you need to have a location-independent package.conf using eg. ${libdir}. Cheers, Simon

1 0