- Libraries - Haskell.org

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 02 Jun '03

02 Jun '03

1 0

Concerning Time.TimeDiff
by Graham Klyne 02 Jun '03

02 Jun '03

Following a brief off-list exchange, Simon Marlow suggested I post some notes here concerning Time.diffClockTimes and Time.TimeDiff. These arise from my thought that the current behaviour of the GHC library in (sometimes) returning a value with positive seconds and negative picoseconds values might be viewed as perverse. I'm trying to go beyond a "what is technically correct" viewpoint to "what is useful"... I understand there's some history here, of which I'm not properly aware, so if this is merely rehashing old ground, please ignore. ... What's useful here? In practice, I think one would want to be able to compare and display time intervals. Maybe the easiest form for doing this (for a multi-component value like TimeDiff) would be a sign+magnitude representation. But TimeDiff doesn't allow for that, so what other options? (a) all components except the most significant are positive, (b) all components the same sign Either of these allows component-wise comparison, from left to right. I think (a) is easiest to format. Of all the options, having the least-significant component negative and the rest positive really seems perverse, as I can't see how to compare or format the value without examining all of the fields before I start. BTW, I'm also dubious about the desirability of including months and years in a time-difference value, because of the variability of months; whenever I've implemented this kind of thing in the past, I use days/hours/mins/secs/sub-secs to measure intervals (though even this is debatable). ... I think it would be helpful if the Haskell Report documentation of diffClockTimes [1] were a little more specific, to the point of stating which way round the subtraction is performed, and also would say something about how negative time-differences should be returned. [1] http://www.haskell.org/onlinereport/time.html: Currently says: [[ Function getClockTime returns the current time in its internal representation. The expression addToClockTime d t adds a time difference d and a clock time t to yield a new clock time. The difference d may be either positive or negative. The expression diffClockTimes t1 t2 returns the difference between two clock times t1 and t2 as a TimeDiff. ]] ... Time representation is something that is difficult to get absolutely right for all purposes, so if the overall design is up for reconsideration I think it's important to have some idea of the intended scope of use. (Pat Hayes summarized some work on the complexity of these issues to a Semantic Web calendaring meeting [2][3].) [2] http://ilrt.org/discovery/chatlogs/rdfig/2002-10-09.html#T11-46-06 [3] http://www.coginst.uwf.edu/~phayes/research.html #g ------------------- Graham Klyne <GK(a)NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E

1 0