- Libraries - Haskell.org

Re[2]: Adding System.FilePath
by Bulat Ziganshin 16 Mar '07

16 Mar '07

Hello Artem, > With FPS i did use the library with GHC 6.4 by fetching and installing > it via Cabal, and with GHC 6.6 it is shipped (thanks for that!). The > same might be done to FilePath: those who need it before GHC 6.8 will > fetch and install it manually (or via hackage), and those who use GHC > 6.8 will have it out of the box. > P.S. > I think it should be possible to install the fresh version of FPS and > GHC compiler should be smart enough to link both the old version (if it > is required by some other part of the base) and the new one... well, i should explain the situation. first, there is no problem to include FPS as *separate* library in GHC and actually 6.6 provides lots of such libs (including ones that was not shipped with 6.4). you don't need to download/install these libraries too FPS is different - it was made a part of base library and this means 1) that .cabal files for libs/apps that uses fps should be different for ghc 6.4 and 6.6 2) that i can't upgrade to newer fps versions 3) that fps versions with api changes can't be used at all with 6.6! all that i propose is to detach fps from base lib and ship it as separate library *together* with ghc -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 1

darcs patch: add hashbang header to Setup.hs
by Ketil Malde 16 Mar '07

16 Mar '07

Thu Mar 15 15:57:23 CET 2007 Ketil Malde <ketil(a)ii.uib.no> * add hashbang header to Setup.hs

2 2

Re: ANN: HSH 1.2.0
by Simon Marlow 15 Mar '07

15 Mar '07

Neil Mitchell wrote: > Hi > >> There are a couple of things about that function... >> >> First, I did see it, but its description is rather vague on what it >> does. From the description, it sounds like it is possible that it >> would not return an absolute path; I read it more as expanding >> symlinks. If it does indeed return an absolute path, I think that >> should be stated explicitly for clarity. > > More fatally it's only implemented on GHC, not for any reason, but > because whoever originally implemented it only used GHC! It's > explicitly #ifdef'd to do nothing (just a return) on other compilers. > I also hate the name. I know plenty of people who wanted the function, > but none who ever found it... I note that the deadline for discussion of System.FilePath has now passed (well, a long time ago :-), so it looks like it's going into base. Any final objections before we do this? Regarding canonicalizePath, I'd be perfectly happy to change its name and/or somehow make it more easily discoverable: does anyone want to make a proposal? Cheers, Simon

7 17

Proposal: Add Data.List.sortNub and sortNubBy
by Neil Mitchell 15 Mar '07

15 Mar '07

Hi, http://hackage.haskell.org/trac/ghc/ticket/1218 I propose the addition of sortNub and sortNubBy. Semantically sortNub = sort . nub Practically, if you are doing both a sort and a nub, this can be implemented as: sortNub = map head . group . sort This is O(n log n) [time to sort], rather than O(n^2) [time to nub]. I have seen this around several times, often called snub. People have also used snub to mean other things, snub itself has a meaning, and sortNub is a more accurate name (following the concatMap tradition). I personally have defined this function at least 25 times, I suspect others have to. I can find 5 identical versions of it on google code [1], and I know google code is lying because it's missing ones it found earlier. Thanks Neil [1] http://www.google.com/codesearch?hl=en&lr=&q=lang%3Ahaskell+%22map+head+.+g…

10 20

Parsec documentation
by Paul Johnson 14 Mar '07

14 Mar '07

I'd like to map the Parsec reference manual into Haddock comments in the sources. Haddock didn't exist when Parsec was created. Which repository is considered the Master for Parsec? Paul.

3 2

System.FilePath patch
by Neil Mitchell 14 Mar '07

14 Mar '07

Hi, A good 3 months after discussion came to a close, here is a patch to implement System.FilePath in the base library. THE IMPLEMENTATION: System.FilePath imports and exports one of System.FilePath.Windows or System.FilePath.Posix based that platform. System.FilePath.Internal.hs is not a real Haskell module, but has all the core code for both the Windows and Posix versions. System.FilePath.Windows/Posix just #include Internal, with the appropriate defines. The actual Internal.hs is all the reviewed code, identical to how it was when agreed upon. NOTES: I've tested the modules as best I can, and they do seem to work, but when it comes to base I'm not entirely sure what I'm doing so, someone might want to take a quick check that I haven't done anything silly. In order to check "am I running on Windows" I have done: #if defined(mingw32_HOST_OS) || defined(__MINGW32__) That is just a complete guess based on what was elsewhere in base. Introducing something semantically better like WINDOWS might be better. TESTING INFRASTRUCTURE: I have a load of tests in the code, along with a utility to generate a test script from Internal.hs. What wants doing with this is someone else's call, the options are: * Don't care about the tests (a bit of a shame) * Run the test generation utility, and shove the result in a testing repo somewhere * Add the test generation utility, and build code to get it all working This can be dealt with after the above patch goes in. Any last comments, or can this be committed? Thanks Neil

3 2

'choice' in Control.Applicative?
by Greg Fitzgerald 14 Mar '07

14 Mar '07

Should there be a 'choice' function in Control.Applicative? choice :: Alternative<http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Applicat…>f => [f a] -> f a choice = foldr (<|>) empty or: choice = Data.Foldable.asum Thanks, Greg

1 0

New ticket #1222 -- Add the "optionMaybe" combinator to Parsec
by Maxime Henrion 13 Mar '07

13 Mar '07

Hello all, I have just created a new ticket (#1222) to suggest the addition of a new parser combinator for Parsec, called "optionMaybe". It is just specialized version of the existing 'option' combinator: it wraps the result into a Maybe type with the expected semantics. As noted in the ticket, it has received positive feedback on the haskell-cafe mailing list and on the #haskell IRC channel. Cheers, Maxime

1 0

Re: [Haskell-cafe] System.Random StdGen read fails on some strings?
by Kirsten Chevalier 13 Mar '07

13 Mar '07

[redirecting from haskell-cafe to libraries] On 3/13/07, Fritz Ruehr <fruehr(a)willamette.edu> wrote: > > According to the documentation for System.Random (see <http://haskell.org/ghc/docs/latest/html/libraries/base/System-Random.html>): > > > > > In addition, read may be used to map an arbitrary string (not necessarily one produced by show) onto a value of type StdGen. In general, the read instance of StdGen has the following properties: > > > * It guarantees to succeed on any string. > * ... > > On the other hand, I get the following on the (admittedly stupid, spur-of-the-moment) String argument "whateva": > > > > > Hugs> :l System.Random > System.Random> read "whateva" :: StdGen > > > Program error: Prelude.read: no parse > > > System.Random> map read $ words "this is a test of the System dot Random StdGen read, which seems to fail only on ... whateva" :: [StdGen] > [4580 1,440 1,101 1,4584 1,445 1,1485 1,35261 1,1377 1,32825 1,34047 1,13422 1,14037 1,13637 1,469 1,4132 1,4514 1,453 1,626 1, > Program error: Prelude.read: no parse > > > Am I missing something here? Or am I just being punished for the stupidity of my particular choice of String? :) > You're being punished for using a string with more than six characters :-) I took a look at the code for System.Random; in particular, the Read instance for StdGen. If you look at the implementation of readsPrec in that instance, it clearly fails on any string longer than six characters that doesn't match [0-9]*[:space:][0-9]* (in that case, stdFromString is invoked, which consumes only the first six characters of the string, hence read says "no parse" if the input string has length greater than six). I'm not sure whether the code is wrong or whether the comment that says "It guarantees to succeed on any string." is wrong. (Or both.) Does anyone know? Cheers, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "The blues isn't about feeling better, it's about making other people feel worse, and making a few bucks while you're at it." -- Bleeding Gums Murphy

2 1

Ann: regex-base-0.91
by Chris Kuklewicz 13 Mar '07

13 Mar '07

I have updated the darcs repository and the hackage repository to have regex-base-0.91 Changes: GHC uses late instance overlap detection, whereas Hugs demands no potential overlap. Thus Hugs rejected some of the polymorphic results for matching given by RegexContext instances. The solution in version 0.91 of regex-base is to use newtypes. To this end there are 4 newtypes which are used to disambiguate some of the more complicated return types of match/matchM/=~/=~~. The new haddock documentation for Text.Regex.Base.Context has more details and lists all the instances. The 4 newtypes are: > newtype AllSubmatches f b = AllSubmatches {getAllSubmatches :: (f b)} > newtype AllTextSubmatches f b = AllTextSubmatches {getAllTextSubmatches :: (f b)} > newtype AllMatches f b = AllMatches {getAllMatches :: (f b)} > newtype AllTextMatches f b = AllTextMatches {getAllTextMatches :: (f b) } The 'f' parameters are containers types, such as [] or (Array Int). The two *Submatches types report all the captured (i.e. parenthesized) groups of the first match found. The two *Matches types report on the all the non-overlapping matches found. This clarifies the desires of the programmer and allows choice of either result to be made. The two *Text* version have the type of the searched text included in the type of the result 'b', unlike the other two types. This avoids overlapping. These newtypes are not used for all the instances, but only where they are needed to either avoid overlapping or remove possible confusion. Using this newtype schema has allowed a few new instances to be added. In particular all the instances should have a [] or (Array Int) option for the returned container. -- Chris Kuklewicz

1 0