November 2004 - Libraries

RE: Proposed addition to Data.FiniteMap
by Simon Marlow 09 Nov '04

09 Nov '04

On 09 November 2004 12:45, Graham Klyne wrote: > I'd like to propose an addition to the FiniteMap module in the form > of a monadic version of plusFM_C. The proposed implementation is > pretty much a copy of the existing implementation within a do block. Data.FiniteMap will shortly be deprecated in favour of DData.Map (which will be renamed to Data.Map when it is imported). Perhaps you'd like to reformulate the proposal using Data.Map instead? Cheers, Simon

1 0

Proposed addition to Data.FiniteMap
by Graham Klyne 09 Nov '04

09 Nov '04

I'd like to propose an addition to the FiniteMap module in the form of a monadic version of plusFM_C. The proposed implementation is pretty much a copy of the existing implementation within a do block. [[ -- | Monadic version of plusFM_C. -- -- The combiner function returns a monadic value, which is threaded though -- the combined elements in key order, yielding a FiniteMap that is bound -- to the same monadic type. The intended use for this is with a Maybe -- monad, allowing result returned to be Nothing if any of the attempted -- combinations of key values return Nothing. Could also be usefully used -- with an error or state monad. plusFM_CM :: ( Ord key, Monad m ) => (elt -> elt -> m elt) -> FiniteMap key elt -> FiniteMap key elt -> m (FiniteMap key elt) plusFM_CM combiner EmptyFM fm2 = return fm2 plusFM_CM combiner fm1 EmptyFM = return fm1 plusFM_CM combiner fm1 (Branch split_key elt2 _ left right) = do { new_l <- plusFM_CM combiner (splitLT fm1 split_key) left ; new_elt <- case lookupFM fm1 split_key of Nothing -> return elt2 Just elt1 -> combiner elt1 elt2 ; new_r <- plusFM_CM combiner (splitGT fm1 split_key) right ; return $ mkVBalBranch split_key new_elt new_l new_r } -- And some test cases: fm1 = listToFM [(1,["a"]),(2,["b","c"]),(3,["d"])] fm2 = listToFM [(1,["b","c"]),(4,["e"])] fm3 = listToFM [(1,["d","e"]),(2,["c","d"]),(4,["f"])] fm12 = Just $ listToFM [(1,["a","b","c"]),(2,["b","c"]),(3,["d"]),(4,["e"])] fm13 = Nothing fm23 = Just $ listToFM [(1,["b","c","d","e"]),(2,["c","d"]),(4,["e","f"])] -- Test function returns Nothing if list values have a member in common: comb ovs nvs | null (intersect ovs nvs) = Just (ovs++nvs) | otherwise = Nothing fmt1 = plusFM_CM comb fm1 fm2 == fm12 fmt2 = plusFM_CM comb fm1 fm3 == fm13 fmt3 = plusFM_CM comb fm2 fm3 == fm23 fmtall = and [fmt1,fmt2,fmt3] ]] ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

RE: [Haskell-cafe] Hal Daume III's NewBinary now ghc6ized, cabalized, debianize, darcsized.
by Simon Peyton-Jones 09 Nov '04

09 Nov '04

Good work! The last thing you need to do is to send a note to John Petersen to incorporate it on the Haskell libraries page haskell.org/libraries. That way lots more people will be able to find it. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | Jeremy Shaw | Sent: 08 November 2004 19:43 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] Hal Daume III's NewBinary now ghc6ized, cabalized,debianize, darcsized. | | Hello, | | I am quite interested in having better Binary support in Haskell -- | especially support for reading and writing binary files and protocols | that have fields smaller than 8-bits and non-byte alignment. | | As a first step, I have republished Hal Daume III's NewBinary package | in hopes that it will inspire some forward movement on it. I have made | the following 'improvements': | | ~ ghc6ized | | cd /tmp/NewBinary/ | diff /tmp/Binary.hs /tmp/NewBinary/NewBinary/Binary.hs | 81c81,82 | < import GHC.Handle ( openFileEx, IOModeEx(..) ) | --- | > import GHC.Handle | > import IOExts ( openFileEx, IOModeEx(..) ) | | (hrm, I probably don't need to import GHC.Handle anymore either...) | | ~ cabalized | | To build, you need the Cabal libraries installed. Then do something | like this: | | ghc -package Setup.lhs -o setup | ./setup configure | ./setup build | ./setup install | ./setup register (? maybe not needed ?) | | ~ debianized | | You should be able to build and install it like any other debian | package: | | dpkg-buildpackage && debi | | ~ darcsized | | darcs get http://www.n-heptane.com/nhlab/repos/NewBinary | | I hope I am not stepping on anyone's toes or duplicating efforts. | | Jeremy Shaw. | | ps. The original is available at: | | http://www.isi.edu/~hdaume/haskell/NewBinary/ | -- | | This message contains information which may be confidential and privileged. Unless you are the | addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone | the message or any information contained in the message. If you have received the message in error, | please advise the sender and delete the message. Thank you. | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: proposal for ghc-pkg to use a directory of .conf files
by Simon Marlow 08 Nov '04

08 Nov '04

On 06 November 2004 10:10, Sven Panne wrote: > Duncan Coutts wrote: >> I can knock up a proof of concept patch if anyone thinks this is a >> good idea. It should be totally backward compatible, it's ok to use >> both, but ditro packagers might like to enforce a policy of using a >> directory of package files for external libraries. > > OK, just send us a patch and if there are no objections we can merge > it into the HEAD. In some ways this looks like a good idea, but it contradicts some of the ideas in the Cabal proposal. There, we were treating the package database as an abstract entity hidden behind the ghc-pkg interface. All interaction with the database would be done via ghc-pkg. The advantages of this abstraction are the usual ones: we might want to change the representation, and the ghc-pkg tool provides a good place to add backwards compatibility if necessary. However, I'm prepared to be persuaded. The "just put a file in this directory" approach to installation is very compelling, being much more transparent. But bear in mind that if we pick this route, then backwards compatibility has to be built into the file format (I think it might be already, but we're planning changes in this area to better support Cabal). Also, there needs to be a way to find the location to install the file - asking ghc or ghc-pkg is the usual way. Cheers, Simon

2 1

proposal for ghc-pkg to use a directory of .conf files
by Duncan Coutts 06 Nov '04

06 Nov '04

Hi, It has been common in recent years since the widespread use of package management systems to break up configuration / settings files that are used by several packages into a directory of individual files rather than modifying a global file. The advantage of doing this is that it makes things easier for the package managers. Each individual file can belong to the appropriate package and so instead of having to execute registration/unregistration actions on install/uninstall it's just another file to add/remove. The other advantage is that there is no longer a global file that needs to be modified which means uninstallation is cleaner (most package managers do not remove files that were modified after installation). So the idea is that in addition to a single $HC-LIB/package.conf file you have a directory of package files $HC-LIB/package.conf.d/*.conf Obviously, the package chasing code needs to be tweaked slightly to slurp in a whole directory of .conf files and $HC-pkg would want to be able to use a directory as an installed package source. I had a peak at the code in ghc for dealing with .conf files. I'd guess it'd be best ok just check if the specified package file is a directory or an ordinary file and act accordingly. Ie you could say "-package-conf packages/" and ghc could by default read from $HC-LIB/package.conf and $HC-LIB/package.conf.d/ or something. I can knock up a proof of concept patch if anyone thinks this is a good idea. It should be totally backward compatible, it's ok to use both, but ditro packagers might like to enforce a policy of using a directory of package files for external libraries. Duncan

2 1

Re: Double -> CDouble, realToFrac doesn't work
by ross＠soi.city.ac.uk 05 Nov '04

05 Nov '04

[switching to libraries] Recap: the definition of realToFrac as going through Rational loses the NaN and +/-Infinity values of Double and Float (though GHC's RULES bypass this). On Thu, Nov 04, 2004 at 08:32:52PM +0100, Sven Panne wrote: > It's an old thread, but nothing has really happened yet, so I'd like to > restate and expand the question: What should the behaviour of toRational, > fromRational, and decodeFloat for NaN and +/-Infinity be? Even if the report > is unclear here, it would be nice if GHC, Hugs, and NHC98 agreed on > something. > Can we agree on the special Rational values below? [The proposal is to add 0:%0, 1:%0 and -1:%0 to Rational.] Changing Rational from meaning rational numbers would also be bad. I'd prefer to redefine realToFrac to go through a new type that is the union of Rational and these values. That would mean adding extended variants of toRational and fromRational to the Real and Fractional classes, with default definitions but overidden for the Float and Double instances. This type and the variant of fromRational might be usable for floating point literals too. > Printing those values could be more consistent for these systems, too, BTW. True, though Hugs is already inconsistent with H98 in its printing of floating point values.

6 9

Cabal on Windows, revisited
by Graham Klyne 03 Nov '04

03 Nov '04

I'm having another go at Building Cabal for Windows, this time using the make utility from mingw. (HMake doesn't serve, as it's specific to compiling Haskell programs. Mainly, I need to get the preprocessing performed for loading into Hugs). Issues noted. ... 1. The "mkdir -p" command fails: under Windows, the syntax of this command is different. I realize there are many other Unix shell commands that just wont work in a make file under Windows, so I'm going to proceed to create a Windows-specific makefile for Hugs. 2. I've replaced the GHC invocations with cpphs, rather like the makefile target for creating documentation. 3. I've changed the temporary target directory to dist\tmp\Distribution (needs to be the right name to match hierarchical module names with Hugs). Also created subdirectory Simple. Also copied Setup.lhs to dist\tmp, and used that as the Haskell program to be run using RunHugs. 4. I also create a target directory and preprocessing commands for the Compat modules: dist\tmp\Compat. 5. At this point, using a batch file to run Setup, I can issue the command Setup --help: [[ E:\HaskellTools\cabal>C:\DEV\Hugs98\runhugs-20040109.exe dist\tmp\Setup.lhs --he lp Usage: disttmpSetup.lhs [GLOBAL FLAGS] COMMAND [FLAGS] Global flags: -h, -? --help Show this help text Commands: configure Prepare to build the package. build Make this package ready for installation. clean Clean up after a build. install Copy the files into the install locations. sdist Generate a source distribution file (.tar.gz or .zip). register Register this package with the compiler. unregister Unregister this package with the compiler. For more information about a command, try 'disttmpSetup.lhs COMMAND --help'. E:\HaskellTools\cabal> ]] It's a small thing, but it looks as if the path separators in 'dist\tmp\Setup.lhs' are being inappropriately interpreted. 6. I tweak the makefile to be sensitive to the presence of 'dist\tmp\Setup.lhs', and running Setup config gives this: [[ E:\HaskellTools\cabal>make config .\Setup configure --hugs --prefix=E:\Temp\Cabal E:\HaskellTools\cabal>RunHaskell dist\tmp\Setup.lhs configure --hugs --prefix E: \Temp\Cabal E:\HaskellTools\cabal>C:\DEV\Hugs98\runhugs-20040109.exe dist\tmp\Setup.lhs configure --hugs --prefix E:\Temp\Cabal Configuring Cabal-0.1... configure: searching for hugs in path. Cannot find compiler for hugs make: *** [config] Error 1 E:\HaskellTools\cabal> ]] I guess this is because of my unusual Hugs setup: (a) I don't have Hugs on the path, and (b) I am currently using a non-standard name for the RunHugs executable. Both problems are resolved if I can override the search for the RunHugs executable with a command line option to specify it. That looks like the "--with-compiler" option. I try using that with the name of my batch file (which is on the path), but get a different error: [[ E:\HaskellTools\cabal>C:\DEV\Hugs98\runhugs-20040109.exe dist\tmp\Setup.lhs configure --hugs --with-compiler RunHaskell --prefix E:\Temp\Cabal Configuring Cabal-0.1... configure: looking for package tool: hugs-package near compiler in RunHaskell Cannot find package tool: ./hugs-package make: *** [config] Error 1 E:\HaskellTools\cabal> ]] OK, it seems to need the actual Hugs executable to find the proper path, so I'll have to make that available and try again: [[ E:\HaskellTools\cabal>C:\DEV\Hugs98\runhugs-20040109.exe dist\tmp\Setup.lhs conf igure --hugs --with-compiler C:\DEV\Hugs98\Hugs.exe --prefix E:\Temp\Cabal Configuring Cabal-0.1... configure: looking for package tool: hugs-package near compiler in C:DEVHugs98Hu gs.exe Cannot find package tool: ./hugs-package make: *** [config] Error 1 E:\HaskellTools\cabal> ]] I note the '\' in the filename are being processed incorrectly again. Also, it still can't find the package tool ./hugs-package. ... That's about as far as I'm going to get here. My makefile so far is: [[ PREF=E:\Temp\Cabal CPPHS=RunHaskell ..\cpphs\cpphs.hs --noline HUGS=C:\DEV\Hugs98\Hugs.exe # build the library itself: for Hugs, this is simply preprocessing into a new directory dist/tmp/Setup.lhs: mkdir dist\tmp\Distribution\Simple mkdir dist\tmp\Compat copy Setup.lhs dist\tmp\Setup.lhs $(CPPHS) Distribution/Package.hs > dist/tmp/Distribution/Package.hs $(CPPHS) Distribution/Misc.hs > dist/tmp/Distribution/Misc.hs $(CPPHS) Distribution/Version.hs > dist/tmp/Distribution/Version.hs $(CPPHS) Distribution/Setup.hs > dist/tmp/Distribution/Setup.hs $(CPPHS) Distribution/ModuleTest.hs > dist/tmp/Distribution/ModuleTest.hs $(CPPHS) Distribution/Simple.hs > dist/tmp/Distribution/Simple.hs $(CPPHS) Distribution/Make.hs > dist/tmp/Distribution/Make.hs $(CPPHS) Distribution/InstalledPackageInfo.hs > dist/tmp/Distribution/InstalledPackageInfo.hs $(CPPHS) Distribution/Simple/Build.hs > dist/tmp/Distribution/Simple/Build.hs $(CPPHS) Distribution/Simple/Install.hs > dist/tmp/Distribution/Simple/Install.hs $(CPPHS) Distribution/Simple/Configure.hs > dist/tmp/Distribution/Simple/Configure.hs $(CPPHS) Distribution/Simple/Register.hs > dist/tmp/Distribution/Simple/Register.hs $(CPPHS) Distribution/Simple/Utils.hs > dist/tmp/Distribution/Simple/Utils.hs $(CPPHS) Distribution/Simple/SrcDist.hs > dist/tmp/Distribution/Simple/SrcDist.hs $(CPPHS) Distribution/Simple/GHCPackageConfig.hs > dist/tmp/Distribution/Simple/GHCPackageConfig.hs $(CPPHS) Distribution/GetOpt.hs > dist/tmp/Distribution/GetOpt.hs $(CPPHS) Compat/Exception.hs > dist/tmp/Compat/Exception.hs $(CPPHS) Compat/H98.hs > dist/tmp/Compat/H98.hs $(CPPHS) Compat/RawSystem.hs > dist/tmp/Compat/RawSystem.hs $(CPPHS) Compat/ReadP.hs > dist/tmp/Compat/ReadP.hs setup-hugs: dist/tmp/Setup.lhs setup: setup-hugs config: setup .\Setup configure --hugs --with-compiler=$(HUGS) --prefix=$(PREF) ]] My Setup.bat file is: [[ rem run setup program for installing cabal rem assumes that RunHaskell utility or batch file is on the path RunHaskell dist\tmp\Setup.lhs %1 %2 %3 %4 %5 %6 %7 %8 ]] My RunHaskell.bat file is: [[ C:\DEV\Hugs98\runhugs-20040109.exe %1 %2 %3 %4 %5 %6 %7 %8 %9 ]] (As I mentioned, I'm using a modified version of RunHugs, hence the unusual filename.) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

3 3

RE: Cabal feedback notes
by Simon Marlow 02 Nov '04

02 Nov '04

On 23 October 2004 10:01, Krasimir Angelov wrote: > One way to make Cabal really portable is to move the > entire platform specific code out of it. One example > is > Distribution.Simple.GHCPackageConfig.localPackageConfig > function, which uses HOME environment variable to > determine the user's home directory, but this doesn't > work under Windows. The CVS System.Directory module > already provides the getAppUserDataDirectory function > which is more suitable (and portable) in this case. localPackageConfig is only for GHC 6.2: in 6.4, GHC and ghc-pkg will know where the local package conf lives, so Cabal won't need this knowledge built-in. > Another example is > Distribution.Simple.Utils.findBinary. Recently I had > updated it and now it is portable but now I see that a > similar function is used in runghc tool but in its non > portable version. If we move this to the standard > libraries then we will be able to use it in both > cases. Most of the other #ifdef-s are related to the > filepath handling. It will be great benefit if we > isolate it in a separate library. I already use the > filepath routines in VSHaskell. You can see that a > similar functions are used in haddock, happy and alex > tools. Maybe if we agree on this it is not too late to > add it before the next GHC release. Last time this came up I asked for a concrete proposal, but no-one came forward with one. I'd do it myself, but I'm kind of busy right now. Would someone care to whip up a list of functions & signatures? I'm inclined to just stick something into the libraries even if it's not perfect. The filename handling issue is one of those things where trying to define a perfectly portable library is hard if not impossible, but having *something* is going to be useful to a lot of people, and as Krasimir says it'll have a lot of duplicated code. Data.FilePath or System.Directory? I'm inclined towards the latter, since we clearly want functions that actually inspect the filesystem (findBinary, getExecutableFilePath) along with functions that just manipulate filenames, and it seems strange to split them up. Cheers, Simon

16 34

Data.List.partition on infinite lists
by Lemming 01 Nov '04

01 Nov '04

I encountered that the implementation of 'partition' in GHC 6.2.1 fails on infinite lists: > partition :: (a -> Bool) -> [a] -> ([a],[a]) > partition p xs = foldr (select p) ([],[]) xs > select p x (ts,fs) | p x = (x:ts,fs) > | otherwise = (ts, x:fs) With the following definition we don't have this problem: > partition :: (a -> Bool) -> [a] -> ([a], [a]) > partition _ [] = ([],[]) > partition p (x:xs) = > let (y,z) = partition p xs > in if p x then (x : y, z) > else (y, x : z) Prelude> take 10 $ fst $ partition even [0..] [0,2,4,6,8,10,12,14,16,18] Prelude> take 10 $ snd $ partition even [0..] [1,3,5,7,9,11,13,15,17,19]

4 3

RE: state of the cabal (preprocessors)
by Simon Marlow 01 Nov '04

01 Nov '04

On 26 October 2004 18:00, Henrik Nilsson wrote: > However, at least superficially, it would seem simpler (and more > flexible, since normal comments would not interfere) to simply > require that all OPTIONS/LANGUAGE pragmas must occur before the > keyword "module". > > But maybe that is hard to implement, or undesirable for some other > reason? Well, it's more tricky because you have to ignore comments, and therefore understand nested comments, but that's not too hard. A little Alex or parsec parser should do the trick, being careful not to read the entire file. I think Cabal could provide the functionality in a library: getOptionsFromSource :: FilePath -> IO ( [Extension], -- LANGUAGE pragma, if any [(CompilerFlavour,[String])] -- OPTIONS_FOO pragmas ) Cheers, Simon

2 1