- Libraries - Haskell.org

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

Re: Using putStrLn/printf from DLL in GUI application
by Simon Marlow 04 Dec '06

04 Dec '06

Krasimir Angelov wrote: > How many times you tried to use putStrLn from Haskell or printf from C > when you are building DLL loaded in GUI application? > > This simply doesn't work because by default the GUI application > doesn't have console window. The solution is to use > allocConsole/freeConsole from the attached library. > > > Example: > > do allocConsole > ..... > ..... > putStrLn "Hello, world!" > ..... > ..... > freeConsole > > This could be a good addition to the standard Win32 library if someone > take care to integrate it. So that we don't lose this: will someone propose a patch to packages/Win32? Cheers, Simon

1 0

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

04 Dec '06

----- Original Message ---- From: Neil Mitchell <ndmitchell(a)gmail.com> >> The deadline is Wednesday, December 6th. > > That's incredibly soon, two days is just not enough time to do > anything! I recommend a minimum deadline of a week for anything, some > people may only catch up with their Haskell mail a couple of times a > week. Will keep in mind for the future submissions. Leave this one as is. It is easy to update the docs later. > As for your patch, I think its great, and its exactly the type of > thing that should be in the libraries documentation for pretty much > everything. My only suggestion would be to include the "corner" cases: > > take 3 [1] = [1] > drop 3 [1] = [] > > (ditto splitAt) > > i.e. show that they produce a result, not an error. I'm for it. Will add. Andriy ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.

1 0

Success Story: Cabal and Dlls
by Jason Dagit 01 Dec '06

01 Dec '06

Hello, I would like to report that I was able to use Cabal with Visual Haskell to build Dlls in windows. I have posted the details about this on the Haskell wiki (and started an extremely minimal Cabal page). If my content is in the wrong place, please feel free to move it (or edit it or whatever). http://www.haskell.org/haskellwiki/Cabal The trick was to take the final HSfoo-0.1.o file generated by the normal build process (and linked with the DllMain.c code) and tell ghc to build a dll. I use -package with each of the dependencies in the cabal file to link with the needed libraries. The resulting dll seems to be working. This approach is a bit hackish and while I've tried to implement as much of it as I can in a general way it requires you to hack your Setup.lhs file if you want to 1) build static 2) specify your exports 3) specify the name of the resulting dll. Also, it's only been tested on my setup which uses Visual Haskell so it may not be fit for general consumption. Finally, I just started really looking at Cabal yestarday so I may not have considered things which an experienced Cabal user would think about. Is it possible to get this functionality built directly into Cabal so that I tell it I want a DLL built from a library and it knows how to make it happen? Thanks, Jason

5 11

Announce of Core (ghc-base) library
by Bulat Ziganshin 01 Dec '06

01 Dec '06

This message is of primary interest for developers of Haskell compilers and core libraries. it duplicated at http://haskell.org/haskellwiki/Library/Core Thanks to Cabal, now we can easily upgrade any installed library to new version. There is only one exception - Base library that is closely tied to compiler internals, so you cannot use Base library shipped with GHC 6.4 in GHC 6.6 and vice versa. The Core library is a project of dividing Base library into two parts - small compiler-specific one (the Core library proper) and the rest - new, compiler-independent Base library that uses only services provided by Core lib. Then, any version of Base library can be used with any version of Core library, i.e. with any compiler. Moreover, it means that Base library will become available for the new compilers, like yhc and jhc - this will required adding to Core lib only a small amount of code implementing low-level compiler-specific functionality. Core library consists of directories GhcCore, HugsCore... implementing compiler-specific functionality and Core directory providing common interface to this functionality, so that external libs should import only Core.* modules in order to be compiler-independent. In practice, implementation of Core lib became a refactoring of GHC.* modules by splitting them into GHC-specific and compiler-independent parts. Adding then implementations of compiler-specific parts for other compilers will allow us to compile refactored Base library by any compiler including old versions of GHC. At this moment, the following modules was succesfully refactored: GHC.Arr, GHC.Base, GHC.Enum, GHC.Float, GHC.List, GHC.Num, GHC.Real, GHC.Show, GHC.ST, GHC.STRef, and the next step is to refactor IO functionality Like the original GHC.* modules, Core library builds up its functionality in layers, where each next layer use features provided by previous ones. Already written layers are, in order of dependencies: Base Integer Integral Float ST/Int/Word Arr Each layer includes both compiler-specific and compiler-independent modules, say first layer is represented by GhcCore.Base/HugsCore.Base and Core.Base modules in contrast to initial design i proposed, compiler-dependent modules in each layer can import and use compiler-independent functionality of previous layers, this greatly simplifies writing of compiler-dependent code and allow to avoid code duplication. For example, GhcCore.* modules widely use && operation defined in Core.Base module. So, when compiling with GHC, dependencies order will be as follows: GhcCore.Base -> Core.Base -> GhcCore.Integer -> Core.Integer -> ... at last end, this mean that Core library can't be split to GhcCore, HugsCore and other separate ones, but need to be united library that includes code for all compilers we support speaking in terms of versions, Base and other higher-level libraries can request specific Core version (say, 2.0.*) and be sure that some set of services should be available. Inside these version range, Core library may grow to support additional compiler versions, say only GHC 6.6 in 2.0.0, GHC 6.6/6.8 and Hugs 2006 in 2.0.1 and so on Why i stopped further development of Core at this stage? First, it was not so hard task - in a week or two i've refactored, afair, 1/3 of GHC.* code. My next goal was to implement Hugs support for all already implemented facilities, but i find serious problems with redefinition of Prelude types and classes. may be, using a feature of upgrading Base, this will become no problem. The same problem, although in less degree, i had with GHC too Second problem that stopped me was I/O part of GHC.* library. It seems impossible to move this out of Core (!) library because Handle type used in definition of Exception type which used by 'fail' for IO Monad and IO monad used everywhere. so, we need some brainstorming to analyze the situation and general tendency of Base library to use too many dependencies. One example was provided by Ross: Data.HashTable is used in Data.Dynamic, that is used in Exception.. so, again, it can't be moved out of Core lib! but even if we can't extract Core library from Base as "compliler-equalizer" subset of modules which includes only Core.* and don't includes Data.*, System.* and other code, at least it's possible to split existing GHC.* code into simple compiler-dependent and more complex compiler-independent parts and simplify way to support 1) new compilers like JHC and YHC 2) range of compiler versions instead of just one version so, i hope that this work will be interesting and helpful for community, especially in order to help new compilers support rich set of libraries with a minimal effort library is available as http://www.haskell.org/library/Core.tar.gz please note that Data.* modules should be considered not as part of library but as examples of modules from future Base library that will be based on services provided by Core -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0