libraries list

The current version of System.Console.GetOpt.getOpt returns a list of values, where the element type has usually one constructor per option. data Flag = Verbose | Version | Input String | Output String | LibDir String What I more like to receive is a record consisting of one constructor and many fields, where optional options are of type Maybe, options with multiple occurrence are of type list. data Flag = Flag { verbose :: Bool, version :: Bool, input :: Maybe FilePath, output :: Maybe FilePath, libdir :: FilePath } Then we would need data ArgDescr a = NoArg (a -> a) ReqArg (String -> a -> a) String OptArg (String -> a -> a) String e.g. OptArg (\path flags -> flags {input = Just path}) "FILE" I feel this approach is so natural, that someone must have implemented it already.

... or, "whoops! I've writtten another html combinator library." History: I was surprised to find that all the Haskell html generating stuff I've tried allowed one to construct invalid HTML. I thought to myself that this might make an undergraduate project, but then I thought "maybe it's too hard? I'd better write some of it to see how hard it is." After a while I decided that it was probably a bit too big for an undergraduate project, but by that time I'd written too much of it to throw away, and just had to keep going so here it is. I'm announcing it here because I hope the audience is fairly small but discerning, and I'm announcing it at all because I've run out of steam for the moment. This is the first code above the size of a nonce-programme that I've written since I got ill years ago, so don't go too hard on me! I still am ill, so don't expect swift responses either. I'm mainly interested in opinions on the questions below, and in test cases that fail validation. You can get it with darcs get --

Hello all, As Thomas Hartman noted in a recent cafe thread [1], haskell 1.3 included the functions 'subsequences' and 'permutations'. I think these functions are quite useful, and I don't know why they were ever removed. This is a proposal to add these two functions to Data.List. The implementation is taken directly from the Haskell 1.3 report [2]. Trac ticket: #1990 Discussion period ends: January 7th (since there is a holiday comming up) Twan [1] http://article.gmane.org/gmane.comp.lang.haskell.cafe/33535 [2] http://haskell.cs.yale.edu/haskell-report/List.html

I was about to update the crypto package when I noticed that there is now a "build log" on each package page. What does this mean and what should I do as package maintainer? Many thanks, Dominic.

Hi all, I just opened a Trac ticket (#1979), to suggest the addition of the inits1 and tails1 functions, which don't return empty lists unlike their counterpart. They're defined as such : inits1 = tail . inits tails1 = init . tails I've needed them a few times so I thought they would make a nice addition to the base package. And, I've got to say, the symmetry in this code is is nice :-). http://hackage.haskell.org/trac/ghc/ticket/1979 Cheers, Maxime

_______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries

Hi Neil, I'm having some problems using filepath in GHC. I think some of these we might have discussed before, but if so I've forgotten what the conclusion was, if any, and I can't see the answers in the docs. The first is this: Prelude System.FilePath> "." "foo" "./foo" which means we get things like [2 of 2] Compiling GHC.Foo ( ./GHC/Foo.hs, ./GHC/Foo.o ) rather than [2 of 2] Compiling GHC.Foo ( GHC/Foo.hs, GHC/Foo.o ) Is there a reason the result shouldn't be "foo"? Possibly relatedly, the current directory seems to be "" rather than ".". This turns up in at least a couple of areas: Prelude System.FilePath> normalise "." "" Prelude System.FilePath> splitFileName "foo" ("","foo") I expected "." and "./" respectively, rather than the ""s. This causes problems when giving arguments to library functions or programs, which generally want "." or "./" rather than "", and if you are displaying a directory to the user then you again probably don't want to

_______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries

I'm making an offer. I need to learn HAppS extremely well over the next couple months. I am willing to document the process by attempting to write detailed documentation on developing applications with HAppS. Something on the order that could be eventually combined into a book, or at least an extensive searchable web site. My current thoughts are to either: 1. Find a free wiki site to do it. 2. Use HaskellWiki 3. Coordinate with Alex regarding the HAppS web site I'm not sure which would be most appropriate. My hope would be to make this public early, since I'm bound to make some mistakes or leave some things out. So I'm sort of counting on getting comments from people who know more than me. Finally, I'm not sure whether code currently in a sufficiently good state that it would be reasonable to write something like this. Perhaps I should hold off and wait for things to stabilize. So: - Is this something people would find helpful? - Should I do it now, or wait? - Which of the choices (1),

Hello, In the documentation for the monad transformer library, the hyperlink http://www.cse.ogi.edu/~mpj/ to Mark P. Jones' homepage is broken. It's used to reference his paper Functional Programming with Overloading and Higher-Order Polymorphism The new location is http://web.cecs.pdx.edu/~mpj/ Regards, apfelmus

From http://haskell.org/haskellwiki/How_to_write_a_Haskell_program#Hierarchical_source there is a link to http://www.haskell.org/~simonmar/lib-hierarchy.html It looks a bit out of date (no Control.Arrow, but DSP instead of Sound). Is there a more current list?

_______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries

To my surprise, if you type ^C at the right moment you can trash GHC's (system-wide) package list. I figured it was easier to reinstall than fix, but forgot Debian installs GHC 6.6 if I don't ask for "unstable". So, let's get Cabal on its feet again: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.6 $ darcs pull Pulling from "http://darcs.haskell.org/cabal"... No remote changes to pull in! $ ghc -i. --make Setup.lhs -o setup Distribution/Simple.hs:114:7: Could not find module `System.FilePath': Use -v to see a list of the files searched for. Can I humbly suggest that Cabal rely on very few external libraries? (I'm switching to 6.6.1 as I type this.) cheers peter

Did you also already need Random instances of enumerations? Wouldn't it be nice to have some helper functions in System.Random: enumRandomR :: (Enum a, RandomGen g) => (a,a) -> g -> (a,g) enumRandomR (l,r) = mapFst toEnum . randomR (fromEnum l, fromEnum r) boundedEnumRandom :: (Enum a, Bounded a, RandomGen g) => g -> (a,g) boundedEnumRandom = enumRandomR (minBound, maxBound) mapFst :: (a -> c) -> (a,b) -> (c,b) mapFst f ~(x,y) = (f x, y) Example application: instance Random Day where random = boundedEnumRandom randomR = enumRandomR

Yes. There are a number of different scenarios for the ordering that you want to use for indexing: 1. A default ordering for the type that is a natural ordering. 2. A default ordering for indexing that is not a natural ordering. 3. An application-specific ordering. 4. More than one ordering for the same type, determined statically. 5. More than one ordering for the same type, determined dynamically, i.e., parameterized orderings. My experience has been that all of these cases do come up quite often in real life. One solution would be to have Data.Map.Indexable, etc. as alternatives using Indexable instead of Ord, so that we could avoid newtype wrapping in case 2. We could allow for case 3 by not providing any default instances for Indexable. Or we could provide default instances in a separate module, Data.Indexable.Instances (or something), that you could choose whether or not to import. Newtype wrapping is still required in case 4, so Indexable doesn't add much here. We have not yet said

_______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries

Here's a patch to IntSet.hs that adds many QuickCheck properties. It adds properties testing almost all of the public interface of IntSet, and also properties testing that the data type invariants are never broken. (The patch doesn't test the Data, Eq, Monoid, Read, or Typeable instances.) Also, this patch removes a helper function, foldlStrict, and replaces it with calls to Data.List.foldl'. I have two questions: 1) Is this the right way to submit patches? 2) Is there a good reason that IntSet doesn't use "deriving Eq", and instead manually implements the Eq instance? New patches: [IntSet QuickCheck properties David Benbennick gmail.com>**20071203040728 1) Remove foldlStrict, and use Data.List.foldl' instead. 2) Add many QuickCheck properties, checking almost every exported function of IntSet. ] { hunk ./Data/IntSet.hs 114 -import List (nub,sort) -import qualified List hunk ./Data/IntSet.hs 115 +import qualified Prelude hunk ./Data/IntSet.hs 315 - = foldlStrict union empty xs + =

I propose to add a Bounded instance to IntSet.hs. IntSet is in Ord, and there are only finitely many instances of IntSet. Therefore there is a min IntSet and a max IntSet. It turns out these bounds are very simple: instance Bounded IntSet where minBound = empty maxBound = singleton maxBound Suggested deadline: December 16, 2007.

_______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries< at >haskell.org http://www.haskell.org/mailman/listinfo/libraries