June 2003 - Libraries

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

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 Utils.hs ...
by Alastair Reid 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? 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. -- Alastair Reid

1 0

RE: Soliciting comments on Edison
by Simon Marlow 04 Jun '03

04 Jun '03

> On Thu, May 29, 2003 at 01:25:10PM +0100, Ross Paterson wrote: > > > I'm not sure that the separate top-level name is justified. > > I'm not so sure about that either, but the hierarchy document had one > last time I looked. At the moment, Edison has its own top-level name in the hierarchy. This was intended to be a temporary measure - ultimately we want a comprehensive library of data structures under Data, but there was a feeling at the time that Edison is not The Right Thing. For my money, I'd be happy with something simpler. Cheers, Simon

2 1

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

03 Jun '03

1 0