- Libraries - Haskell.org

FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Alain Cremieux 20 Jan '05

20 Jan '05

>As I see it: we could change all the operations in Data.Set/Data.Map to >be right-biased, but that's a fair bit of work and might introduce new >bugs. > >If someone wants to do this work, it needs to be done fairly quickly >(i.e. in the next couple of weeks) because we plan to release GHC 6.4 >with the new code, and we won't be able to make further library changes >until 6.6. Any volunteers? > >Cheers, > Simon > > Hi, If everyone agrees on what's to be done, I volunteer for doing it. Alain

2 1

Data.Map.splitLookup
by Ross Paterson 18 Jan '05

18 Jan '05

Currently there is splitLookup :: Ord k => k -> Map k a -> (Maybe a,Map k a,Map k a) returning the matching element (if any) and the submaps less and greater than the key. I think it would be neater to return the element in the middle: splitLookup :: Ord k => k -> Map k a -> (Map k a,Maybe a,Map k a) Perhaps Data.Set.splitMember should similarly be changed from splitMember :: Ord a => a -> Set a -> (Bool,Set a,Set a) to splitMember :: Ord a => a -> Set a -> (Set a,Bool,Set a)

1 0

RE: cabal posix build-depends issue
by Simon Marlow 18 Jan '05

18 Jan '05

On 17 January 2005 18:24, Malcolm Wallace wrote: > Isaac Jones writes: >>> If it depends on posix, on a non-posix system, the user will get an >>> error because the posix package doesn't exist. >>> >>> If it doesn't depend on posix on a posix-based system, then ghc >>> won't get the -package posix flag, and so cabal will fail to link. > > There is a further problem: nhc98 has neither posix nor util packages, > so a straightforward dependency on either would be wrong. In general yes - in this particular case I don't see why nhc98 can't provide the unix package (not the posix package - that's the old non-hierarchical version, sorry for the confusion). There might be minor porting issues, but it's mostly just FFI code. > Simon Marlow writes: >> My gut feeling is that we should be able to say something like >> build-depends: if-not-os("mingw32",unix >= 1.0) > > I would agree that we need platform-selected dependencies. Platform > includes compiler, compiler version, OS, and possibly OS version. Yup. Cheers, Simon

1 0

RE: FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Simon Marlow 18 Jan '05

18 Jan '05

On 17 January 2005 19:59, Iavor Diatchki wrote: > On Mon, 17 Jan 2005 16:04:29 -0000, Simon Marlow > <simonmar(a)microsoft.com> wrote: >> If someone wants to do this work, it needs to be done fairly quickly >> (i.e. in the next couple of weeks) because we plan to release GHC 6.4 >> with the new code, and we won't be able to make further library >> changes until 6.6. Any volunteers? > > It seems strange to me that the DData library and GHC need to evolve > at the same rate. > Why not have a library website where interested programmers can go and > download the > latest version of the library? Absolutely, that's the direction we want to move in with Cabal and Hackage. But at the moment, GHC is shipped with a monolithic collection of libraries, and we make certain promises about when we change those interfaces. Don't worry, in the future you'll be able to upgrade most libraries independently of GHC (and get a whole new set of problems :-). Cheers, Simon

1 0

RE: haddock command in cabal
by Simon Marlow 18 Jan '05

18 Jan '05

On 18 January 2005 00:39, Isaac Jones wrote: >> - should process hidden modules as well as exposed ones. The >> hidden modules might contain entities that are re-exported by an >> exposed module. Hidden modules should use the #hide haddock >> directive. > > This is a bit yucky... AFAICT, it's not currently possible to tell > haddock either via the command-line or via a config file or something > which modules should be hidden? One option is to munge the source > code (hell, we're running cpphs on it, so we might as well, 'eh?). > Could we get some way to do this with the command-line in future > versions of haddock? Sure. For now, the workaround is for the programmer to add -- #hide to each hidden module. >> - we should install the haddock interface, and fill in the >> location in haddock_interfaces. Similarly for the HTML, and >> haddock_html. > > I don't understand that part. Is hadock_interfaces something in GHC's > package config file or something? It's in the InstalledPackageConfig. For an ordinary package, I'd expect that we should install the Haddock docs like this on Unix: $prefix/share/doc/<package>/<package>.haddock $prefix/share/doc/<package>/html/... and then the InstalledPackageConfig should contain haddock_interface: $prefix/share/doc/<package>/<package>.haddock haddock_html: $prefix/share/doc/<package>/html In the future, Haddock will be able to use this information when building documentation, so you'll be able to give -package flags to haddock. Cheers, Simon

1 0

Re: [Haskell] signature of when, unless
by Isaac Jones 17 Jan '05

17 Jan '05

Frederik Eaton <frederik(a)ugcs.caltech.edu> writes: > Wouldn't it be more useful if the type was > > when :: Monad m => Bool -> m a -> m () > > not > > when :: Monad m => Bool -> m () -> m () Seconded. peace, isaac

1 0

haddock command in cabal
by Isaac Jones 17 Jan '05

17 Jan '05

[Moved from cvs-libraries(a)haskell.org] "Simon Marlow" <simonmar(a)microsoft.com> writes: > On 10 January 2005 04:08, Isaac Jones wrote: >> added ./setup haddock cmd. works on exposed-modules >> >> It requires both haddock and hscpp; Fix to not require cpp if it's >> not needed. >> >> It runs the cpp over the files first and unlits .lhs files. >> >> Along the way, cleaned up the command-line parser to re-use code for >> commands with no arguments. >> >> Changed the type of withLib to be more general > > Cool! Some items for the ToDo list. I'll try to help out with these > later, right now I'm focussed on GHC 6.4: I added these to the TODO list. > - should process hidden modules as well as exposed ones. The hidden > modules might contain entities that are re-exported by an exposed > module. Hidden modules should use the #hide haddock directive. This is a bit yucky... AFAICT, it's not currently possible to tell haddock either via the command-line or via a config file or something which modules should be hidden? One option is to munge the source code (hell, we're running cpphs on it, so we might as well, 'eh?). Could we get some way to do this with the command-line in future versions of haddock? > - configure should detect haddock. We should have a > --with-haddock too (similarly for all the other programs we use - I > made this change for VS a while ago and didn't get around to pushing > it, now it'll be conflict city. oh well). I added this. If it's given a --with-haddock, then it'll always use that. If not, then it tries to find one. If it can't find one in the path, then it tries to find it again when you run ./setup haddock. > - if GHC is present and hscpp is not, we can use 'ghc -E -cpp'. This > also unlits. > > - hscpp need to define __HADDOCK__ when preprocessing for haddock. > This means we have to preprocess seprately for haddock. > > - haddock should be passed the names of the interface files for the > dependent packages (gotten from haddock_interfaces field of the > dependent packages, query ghc-pkg). I haven't done any of that yet. > - we should install the haddock interface, and fill in the > location in haddock_interfaces. Similarly for the HTML, and > haddock_html. I don't understand that part. Is hadock_interfaces something in GHC's package config file or something? peace, isaac

1 0

ANN: Cabal 0.4
by Isaac Jones 17 Jan '05

17 Jan '05

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, with a 0.4 version 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/ ------------------------------------------------------------ -*-change-log-*- 0.4 Isaac Jones <ijones(a)syntaxpolice.org> Sun Jan 16 2005 * Much thanks to all the awesome fptools hackers who have been working hard to build the Haskell Cabal! * Interface Changes: ** WARNING: this is a pre-release and the interfaces are still likely to change until we reach a 1.0 release. ** Instead of Package.description, you should name your description files <something>.cabal. In particular, we suggest that you name it <packagename>.cabal, but this is not enforced (yet). Multiple .cabal files in the same directory is an error, at least for now. ** ./setup install --install-prefix is gone. Use ./setup copy --copy-prefix instead. ** The "Modules" field is gone. Use "hidden-modules", "exposed-modules", and "executable-modules". ** Build-depends is now a package-only field, and can't go into executable stanzas. Build-depends is a package-to-package relationship. ** Some new fields. Use the Source. * New Features ** Cabal is now included as a package in the CVS version of fptools. That means it'll be released as "-package Cabal" in future versions of the compilers, and if you are a bleeding-edge user, you can grab it from the CVS repository with the compilers. ** Hugs compatibility and NHC98 compatibility should both be improved. ** Hooks Interface / Autoconf compatibility: Most of the hooks interface is hidden for now, because it's not finalized. I have exposed only "defaultMainWithHooks" and "defaultUserHooks". This allows you to use a ./configure script to preprocess "foo.buildinfo", which gets merged with "foo.cabal". In future releases, we'll expose UserHooks, but we're definitely going to change the interface to those. The interface to the two functions I've exposed should stay the same, though. ** ./setup haddock is a baby feature which pre-processes the source code with hscpp and runs haddock on it. This is brand new and hardly tested, so you get to knock it around and see what you think. ** Some commands now actually implement verbosity. ** The preprocessors have been tested a bit more, and seem to work OK. Please give feedback if you use these. 0.3 Isaac Jones <ijones(a)syntaxpolice.org> Sun Jan 16 2005 * Unstable snapshot release * From now on, stable releases are even. 0.2 Isaac Jones <ijones(a)syntaxpolice.org> * Adds more HUGS support and preprocessor support.

1 0

FW: FW: cvs commit: fptools/libraries/base package.conf.in fptools/libraries/base/Data IntMap.hs IntSet.hs Map.hs FiniteMap.hs Set.hs
by Simon Marlow 17 Jan '05

17 Jan '05

Here's a reply from Daan. As I see it: we could change all the operations in Data.Set/Data.Map to be right-biased, but that's a fair bit of work and might introduce new bugs. If someone wants to do this work, it needs to be done fairly quickly (i.e. in the next couple of weeks) because we plan to release GHC 6.4 with the new code, and we won't be able to make further library changes until 6.6. Any volunteers? Cheers, Simon On 17 January 2005 12:32, Daan Leijen wrote: > Simon Marlow wrote: >> Daan - any comments on this? In the absence of any objections, I'm >> tempted to change it back. > > Hi Simon, > > All the operations in (the original) DData are left-biased. I made > this choice since the container is always the last argument, and than > it makes sense for insert that it is left-biased -- the new value > overwrites the on in the container. > > I believe that most operations in the original Data.Set / > Data.FiniteMap are right-biased however -- except for functions like > insert etc. > > This is very confusing indeed! So, there are a two choices: > 1) convert to the DData bias -- silently introducing bugs in old code > 2) convert DData to be right-biased -- not so consistent, but at least > it would be bug compatible. > > The second choice is probably best, but I didn't want to do that as it > seems a lot of work since it has to be done very carefully to avoid > introduction of bugs. I don't really know what the community thought > which choice was best -- maybe JP knows more about this? > > I hope this helps, > -- Daan. > > ps. Before you start releaseing 6.4, can we discuss the "reloading > of dynamic libraries" in ghci again? You once gave a technical > answer, but just a straightforward solution would be great -- > even when it is as slow as restarting ghci, it is still very > convenient > to have a single command for reloading. > > >> >> Cheers, >> Simon >> >> On 16 January 2005 12:38, Sven Panne wrote: >> >> >>> Simon Marlow wrote: >>> >>>> simonmar 2005/01/13 02:37:39 PST >>>> >>>> Modified files: >>>> libraries/base package.conf.in >>>> libraries/base/Data FiniteMap.hs Set.hs >>>> Added files: >>>> libraries/base/Data IntMap.hs IntSet.hs Map.hs Log: >>>> Add Data.Map, Data.Set, Data.IntMap and Data.IntSet from Daan >>>> Leijen's DData library, with some modifications by JP Bernardy and >>>> others on the libraries(a)haskell.org list. Minor changes by me to >>>> remove the last references to DData, and add a DEPRECATED copy of >>>> the old Data.Set interface to the new Data.Set. >>>> >>>> Data.FiniteMap is now DEPRECATED. >>>> >>>> Revision Changes Path >>>> 1.11 +3 -0 fptools/libraries/base/package.conf.in >>>> 1.20 +5 -1 fptools/libraries/base/Data/FiniteMap.hs >>>> 1.8 +1096 -69 fptools/libraries/base/Data/Set.hs >>> >>> I must admit that I didn't follow the data structure discussion in >>> every detail, but I find something confusing: In >>> Data.FiniteMap.addListToFM_C, >>> the combining function gets the old value as the 1st argument and >>> the new value as the 2nd one. In Data.Map.insertWithKey (and >>> friends), this seems to be the other way round, which is >>> undocumented and *very* confusing when trying to port things from >>> FiniteMap to Map. Is there a deep reason for this? >>> >>> Cheers, >>> S. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/libraries

3 2

RE: cabal posix build-depends issue
by Simon Marlow 17 Jan '05

17 Jan '05

On 16 January 2005 00:32, Isaac Jones wrote: > I have a bit of a problem with Cabal's need to build-depend on posix. > I'm building cabal with itself, and I think this is what's happening: > > If it depends on posix, on a non-posix system, the user will get an > error because the posix package doesn't exist. > > If it doesn't depend on posix on a posix-based system, then ghc won't > get the -package posix flag, and so cabal will fail to link. > > On the other hand, "depends" in the cabal sense is meant to be a > static value; not dependent on what kind of system you are > using... it's kinda funny to say "if you're on a posix system, then > cabal depends on posix." > > Cabal doesn't _really_ depend on POSIX... it only does in its Compat > libraries, and we could get rid of all the POSIX code. > > I think another ugly workaround is to have cabal depend on "util" or > something, since that package depends on posix on a posix system, and > presumably it doesn't depend on posix on a non-posix system. Depending on "util" isn't entirely satisfactory, because util is an old non-hierarchical package which is going away soon. I don't see a good way around this one, in general. It would be nice to have no system-dependent package dependencies, but is that practical? It means we have to have a "dummy" unix package on those platforms which don't support it, which seems even uglier than an explicit platform-dependency in the build-depends list. My gut feeling is that we should be able to say something like build-depends: if-not-os("mingw32",unix >= 1.0) This is pretty easy to implement, and since we get to pick a well-defined syntax, separate tools that read the .cabal file can grok it too. Cheers, Simon

2 1