December 2006 - Libraries

Re: Data.List documentation improvements
by Andriy Palamarchuk 08 Dec '06

08 Dec '06

The deadline for this update is up. Can somebody commit the changes for me? Here is the ticket with the patch: http://hackage.haskell.org/trac/ghc/ticket/1034 Andriy ____________________________________________________________________________________ Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index

6 6

Re: Data.List documentation improvements
by Andriy Palamarchuk 07 Dec '06

07 Dec '06

Iavor, thank you for the feedback. ----- Original Message ---- From: Iavor Diatchki <iavor.diatchki(a)gmail.com> > instead of adding examples to the documentation, wouldn't it be better > to have a wiki site that documents the libraries, and everyone can add > examples there. I am thinking something along the lines of: > http://us2.php.net/manual/en/function.fopen.php Depends on what examples we are talking about. I'm strongly in favor of including examples explaining API definition and intended usage in the library documentation. Think about these examples as of other way of defining the API. Code can explain some things much better that words, right? On other hand examples of using API in broader context, recipes, design patterns, discussions do not belong to the API documentation, though some information can eventually migrate there :-) > PS: I find the darcs patches that are being sent _very_ unreadable: > they contain tons of information that is not at all relevant to the > change that was made. Is there a simpler way to show what was done? > Perhaps a simple diff? Isn't header of the darcs patch is essentially a diff? I agree with you that darcs patch takes a lot of space because of additional data. To work around that one can attach patches to the ticket instead of emailing them to the list. Ticket for this problem is: http://hackage.haskell.org/trac/ghc/ticket/1034 Besides the patch you'll find there HTML document with haddock output from the changes. Andriy ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

1 0

Re: Re[2]: [GHC] #974: Add unzipEithers, lefts, rights to Data.Either
by Andriy Palamarchuk 07 Dec '06

07 Dec '06

Sorry, I was not subscribed when the discussion started. I do not mind against name separateEithers. A couple of ideas: * decideEithers (or decideOnEithers). * an entry from thesaurus for "split" (http://thesaurus.reference.com/browse/split) may help to pick good name: bifurcate, branch, break, burst, cleave, come apart, come undone, crack, dichotomize, disband, disjoin, dissever, disunite, diverge, divide, divorce, fork, gape, give way, hack, isolate, open, part, part company, pull apart, put asunder, rend, rip, rive, separate, sever, splinter, sunder Andriy PS: "bifurcateEithers" - good candidate for a spelling bee :-))) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [GHC] #974: Add isLeft, isRight, fromLeft, fromRight, and splitEithers to Data.Either
by dons＠cse.unsw.edu.au 07 Dec '06

07 Dec '06

ndmitchell: > Hi > > >#974: Add isLeft, isRight, fromLeft, fromRight, and splitEithers to > >Data.Either > > Woohoo! Finally! > > >This proposal would add basic functionality to `Either` similar to that > > for `Maybe`. The `splitEithers` function of type `[Either a b] -> > > ([a],[b])` is unique; however, it seems to be a widely useful function. > > This (in my mind) is a parallel to unzip? unzipEithers to me gives a > much clearer picture of what is going on here. yeah, if its an unzip, then unzipEithers makes more sense. -- Don

10 30

Data.List documentation improvements
by Andriy Palamarchuk 06 Dec '06

06 Dec '06

Goal of my changes it to make list functions more accessible to Haskell newcomers. "Extracting sublists" section seems to have less complete documentation than rest of the module. Added examples for all the functions. Added easier to understand summaries for composite functions. Comments, suggestions, better descriptions? Is it Ok to send the darcs patches as is or it is better to send only diffs without context? I'd like to keep patch in plain text, not compressed. Thanks, Andriy __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

cabal/haddock features
by Johannes Waldmann 06 Dec '06

06 Dec '06

yeah, great tools, but .. * when Cabal(-1.1.6) sees a wrong entry in "exposed-modules" (a module whose source cannot be found) it says "Parse of field 'exposed-modules' failed:" with an unhelpful line number (the line where the field starts, not the line where the error occurs) * is there a simple way to "expose" all modules in a source tree? Perhaps: exposed-modules: Foo.Bar.*; Baz.* I have to generate "exposed-modules" by some find/sed hackery, But I want to use Cabal exactly to avoid such extra tools. * when a *.cabal file specifies both a library and an executable that uses this library, the build process compiles all files twice, once for the library, once for the executable? (This may be my misunderstanding of some options/fields.) * haddock(-0.8) does not understand ghc-6.6's new syntax, e.g. foo :: Bar <- baz (withouth parens around the lhs) that is bad because now I have to rewrite my code. * why does haddock *die* in such cases? it has no business parsing the code anyway, as it should only care for declarations. (yes it needs to find the next declaration but couldn't this be done more generously?) (no, since what looks like a decl. could in fact be inside a block comment - but that's already known after scanning, and before proper parsing?) I'd try to help by coding some patches but I don't follow the development closely, so I ask if perhaps someone already is working in it or at least has a roadmap for work. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

4 3

Control.Monad.Identity documentation
by Andriy Palamarchuk 06 Dec '06

06 Dec '06

Control.Monad.Identity Haddock documentation. Jeff Newbern gratiously gave permission to include monad descriptions from his cool tutorial "All About Monads" (http://www.nomaware.com/monads/) in the library documentation, so I added his description of the Idenitity monad. Also converted existing module comments to Haddock format. Attached Haddock output for the module. You can get the updated module source from the proposal ticket (http://hackage.haskell.org/trac/ghc/ticket/1039) Proposal deadline is December 19 (in 2 weeks). Comments, suggestions? Any notes on motivation? Do you like the itemized overview (Computation type, Strategy, etc.)? Andriy ____________________________________________________________________________________ Need a quick answer? Get one in minutes from people who know. Ask your question on www.Answers.yahoo.com

1 0

Re: Data.List documentation improvements
by Andriy Palamarchuk 05 Dec '06

05 Dec '06

Thank you for the comments! New version of the patch - per earlier suggestions added examples for corner cases. The patch is attached to the ticket on http://hackage.haskell.org/trac/ghc/ticket/1034 Here I attached HTML file showing Haddock results for the affected part of documentation. Hope this is easier to read than patch. I decided to leave QuickCheck-style properties out of scope for this patch. Andriy ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com

1 0

darcs patch: Don't try to build cbits/Win32Utils.c on POSIX systems
by stefanor＠cox.net 04 Dec '06

04 Dec '06

Sat Dec 2 20:49:41 PST 2006 stefanor(a)cox.net * Don't try to build cbits/Win32Utils.c on POSIX systems

2 1

base libraries
by Bulat Ziganshin 04 Dec '06

04 Dec '06

Hello libraries, current situation when Base lib includes everything, from 'const' to starship control, creates serious problems for upgrading to next GHC version. this problem arise because every GHC version arrives with its own, non-upgradable version of Base library and even minor API changes here results in total loss of ability to use new ghc version without #ifdef workarounds it seems strange, but even in this situation some developers prefer to include their modules in base lib instead of providing them as separate libs that can be easily upgraded using Cabal so that any library version can be used with any version of ghc after analyzing the situation, i concluded that source of problem, at least partially, is GHC HQ's policy of packaging libraries with GHC. The list of such libraries is *closed* and odd at first look. why, for example, it includes 2 of 4 regexp libs? at last end, we can learn that this is the list of libs required to build ghc itself! unfortunately, ghc building process don't require FilePath or ByteString support. this results in situation when authors of these libs, looking for a way to include their libs in every ghc distro, don't find other solution except for including them in Base lib. moreover, while Simon & Ian argued against inclusion of these very useful libs in base libs set, they don't have anything against inclusion of the same code in Base lib i'm all for docracy, but not in this case. having the experience of patching the program after each ghc upgrade, and having a bunch of conditionally compiled code in my libs, i can easily imagine ghc version hell that these new modules will provide for us so, i think, it is time to revise ghc libraries policy. i propose to split libs into the 3 "rings": core, base and other * core libs includes ghc version dependent libs. currently it's base, stm and th * base libs are libs, which is guaranteed to be shipped with *every* haskell distribution. on windows, it should be a part of monolithic installer while on unixes these libs may be a separate packages, but porters should ensure that they ported all these libs too this set should include only small and widely used libs, what is mainly datastructure processing ones. my current list includes regexps, bytestring, filepath, time, mtl, fgl, newbinary and so on * other libs are either too specific or too large, such as gui, database and xml ones. these may be included in some distros or installed separately these rules don't say anything about ghc self-building process. it will be great to maintain the list of libraries, required to do it, separately and while we are here - splitting of Base library should be very easy task. its ghc version specific part is in GHC.* modules. these modules should be moved into the new Core library. plus a few modules from Data.* or System.* hierarchy they imports. plus a few modules imported by Hugs/NHC Prelude. the rest of Base library should be pretty portable, at least between various GHC versions. and independent on this work, we can always look into moving pieces of Base into independent libs. as a rule of thumb, everything not used in Base lib may be moved outside of it. of course, these new libs should be included in base libs set in particular, my hottest hope is that ghc 6.6.1 will be shipped with fps 0.8 as separate library that will provide both backward compatibility with 6.6 and will allow to upgrade fps without recompiling ghc itself :D -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

15 77