- Libraries - Haskell.org

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

install targets on package building infrastructure
by Alastair Reid 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) -- Alastair

1 0

RE: Haskell library infrastructure coordinator
by Simon Marlow 05 Jun '03

05 Jun '03

Isaac Jones writes: > Here are some suggestions on how you might proceed usefully and give > us some time to come up with a plan for a build system > > - collect the libraries that are already included with various > compilers and see what the differences are both in what libraries > are included and behaviors of the libraries Are you aware that the three main compilers (GHC, nhc98 and Hugs) are all working from the same set of library sources these days? In the CVS repository on cvs.haskell.org, in the directory fptools/libraries, are the libraries that GHC, Hugs and nhc98 are all shipped with. These libraries are maintained by various people. They follow the guidelines in the library document: http://www.haskell.org/hierarchical-modules/libraries/libraries.html I doubt that we want to replace these libraries with another distribution. Let's not forget: the problem which originally prompted this discussion is that this set of libraries is about as large as we can reasonably distribute with the compilers. The idea was to develop a build/distribution system to make it easier for third-party library developers to distribute their work, without relying on the compiler developers to do it. > - find orphaned libraries (ala Numeric Quest) and try to find the > authors to give them licenses. > > - some documentation for standards lightly based on the libraries > currently included w/ compilers. The document I referred to above has guidelines for library design. > These will probably want to include > some reference to various licenses. The document I referred to above has a section on licenses. Cheers, Simon

3 2

RE: Qustions about hierarchaly library conventions
by Simon Marlow 05 Jun '03

05 Jun '03

> I have a qustion about a convention when writing a hierarchal library. > > Lets say I have a library > > A.B.C > > with modules > > A.B.C > C1.hs > C2.hs > C3.hs > > Is there a convention (official or not) as to when there is a parent > module (in the example above, C.hs) that imports and re-exports the > various sub-modules? There are some suggestions here (see "Module naming conventions"): http://www.haskell.org/hierarchical-modules/libraries/layout.html Further ideas for fleshing this out are welcome. > For example, in the standard libraries, there is a Foreign module that > re-exports most of Foreign.*. But there isn't a > System.Posix; you have > to import the System.Posix.Signal and System.Posix.Types individually. There is a System.Posix. It's in the 'unix' package, but you don't have to say anything to get it: Prelude> System.Posix.epochTime >>= print Loading package unix ... linking ... done. 1054801650 Having the documentation separated into packages is perhaps the confusing thing here - System.Posix.Signals and System.Posix.Types are in the base package, whereas the rest of System.Posix is in the unix package. Cheers, Simon

1 0

Qustions about hierarchaly library conventions
by Matthew Donadio 04 Jun '03

04 Jun '03

Hi all, I have a qustion about a convention when writing a hierarchal library. Lets say I have a library A.B.C with modules A.B.C C1.hs C2.hs C3.hs Is there a convention (official or not) as to when there is a parent module (in the example above, C.hs) that imports and re-exports the various sub-modules? For example, in the standard libraries, there is a Foreign module that re-exports most of Foreign.*. But there isn't a System.Posix; you have to import the System.Posix.Signal and System.Posix.Types individually. Thanks. -- Matthew Donadio (m.p.donadio(a)ieee.org)

1 0

RE: cvs commit: fptools/libraries/base/Control/Monad/X Cont.hs ContT.hs Error.hs ErrorT.hs Fix.hs Identity.hs Monads.hs Nondet.hs NondetT.hs README Reader.hs ReaderT.hs Resume.hs ResumeT.hs State.hs StateT.hs Trans.hs Transformers.hs Types.hs Uti
by Simon Marlow 04 Jun '03

04 Jun '03

> On Tuesday 03 June 2003 11:26 pm, diatchki(a)glass.cse.ogi.edu wrote: > > Added files: > > libraries/base/Control/Monad/X Cont.hs [...] > > Log: > > Added a first version of the new monad library (experimental). > > Hopefully one day the "X" will disappear. > > What's the policy on adding large directory trees of > experimental code to existing libraries like base? We don't have one. Yet ;-) > Some obvious options: > > 1) Go right ahead - no need to mark it specially > > 2) Go right ahead but be sure to use an X prefix to warn > people - we'll delete the X once it is finalized. > > 3) It'd be better to do the development in a separate library tree > such as fptools/libraries/newmonads. > > a) And give it a name like Unsafe.Control.Monad.Cont > b) And give it a name like Org.Diatchki.Control.Monad.Cont > c) And give it a name like Control.Monad.Cont > > I lean towards either (1) or (3) and can't decide between 3a/b/c. > > (3) seems most in keeping with the push for a library infrastructure. I agree with either (1) or (3). (1) is arguably OK because these libraries are currently marked experimental. (3a) or (3b) is arguably better because it gives people a chance to comment on the code before it goes in. (3c) is the same as (1) except that the code is physically separate in the repository: I think this is a good idea regardless, as long as we don't envisage adding dependencies on the new code into base at some point, which would mean moving it all back in again. Summary: - The new monad library should go in a package of its own (fptools/monads?). - I suggest putting it under Unstable for the time being, then moving it to the proper place in the hierarchy later, deleting the existing Control.Monad.Stuff at the same time. I know that moving whole libraries around in the hierarchy is painful at the moment. Simon P.J. and I have been devoting some brain cycles to this problem, and we hope to have a proposal soon. Cheers, Simon

3 2

Name allocation (was: RE: Haskell library infrastructure coordinator)
by Simon Marlow 04 Jun '03

04 Jun '03

Peter Simons writes: > I'd like to have complementary libraries in there. For instance: I > have written a set of QuickCheck combinators, which can be used to > generate random expressions to test parsers. If this were to be added > to "hslibs", it would probably go to "Debug.QuickCheck.Parser". > > Of course, we could add a prefix like "HSLibs" to _all_ libraries > included in the repository, to make sure they don't collide with the > standard ones, but IMHO this is overkill. It's also not a guarantee that your libraries won't collide. The only way (currently) to have such a guarantee is to use User.To.Cryp.Simons as the root of your library tree. Perhaps there's a demand for a part of the hierarchy that is a "free for all", with no formal process for acquiring names, where collision is "at your own risk". Suggestions for the root name for this hierarchy are welcome: Unstable or Temp perhaps? Cheers, Simon

7 7