April 2010 - Haskell-Cafe

ghc #defines
by gladstein＠gladstein.com 14 Apr '10

14 Apr '10

I may need to put some #ifdef conditionalizations into some cross-platform code. I'm wondering where I can find the definitions of symbols like __NHC__. I tried googling but I'm swamped by uses, no definitions that I can see.

3 2

a way to convert partial functions to functions with Maybe's
by Ozgur Akgun 14 Apr '10

14 Apr '10

Cafe, Is there a way (without going into the IO lands) to achieve this: data T = A | B | C func1 :: T -> T func1 A = B func1Fixed :: T -> Maybe T func1Fixed A = Just B func1Fixed _ = Nothing I want a function to generate func1Fixed, given func1. I guess this is doable with exception handling (catching the error from func1)? Is it the only way? Best, -- Ozgur Akgun

5 5

unboxed types in classes
by Phyx 14 Apr '10

14 Apr '10

Hi all, I was wondering if it's possible to have a class declaration that would except both unlifted types and lifted types as instances. For instance, I'm looking for something like class Foo a b where bar :: a -> b instance Foo Int Int where bar = id instance Foo Int# Int where bar = iBox Regards, Phyx

2 1

Cabal dependency hell
by Maciej Piechotka 14 Apr '10

14 Apr '10

While I love Haskell it's packaging system have some problems - especially with parsec. Currently I'm not able to install an practically anything using cabal due to version mismatches (or at least packages linking to both version of parsec). I found the following problems in various cabal packages (the examples are only examples - please do not be offended): - The constraints are too loose. It is written that package works with '>0.6 && <1' but in 0.8 the API has been changed (example of tagsoup & hxt. Fixed hxt versions depends on ghc 6.12... and ghc 6.10 if you change 2 lines in cabal file) - The constraints are too tight. It is written that package works with 'parsec <3' but it can run with 3.0 and 3.1 (a lot of packages) Additionally: - Monomorphism restriction & autodetection of types may cause that extending interface (such as changing signature from a -> IO a to MonadIO m => a -> m a) may break some programs - You cannot change the restrictions on already submitted programs. If I figure out that due to minor change my package does not work with parsec 3.1 I can push the new version with fix but there is no way to mark package on hackage as 'this version is not compatible with parsec >=3.1' I understand that it is not problem only with haskell/cabal but also with many other packaging systems - especially those language-specific. I understand the need of ability of changing API (and haskell-specific problem what constitutes as API change). However I hope that some improvements are possible. Best regards PS. I understand that content may be flame-gen. I am sorry in advance if such circumstances happen. However I believe that possible improvements in process are worth the risk.

13 21

GSoC: Hackage 2.0
by Matthew Gruen 13 Apr '10

13 Apr '10

Hi Haskellers, I'm Matt Gruen (Gracenotes in #haskell), and the Hackage 2.0 SoC project at <http://hackage.haskell.org/trac/summer-of-code/ticket/1587> really piqued my interest. It seems doable, in a summer, to make the new hackage-server more-than-deployment-ready as well as clearing out some items in the hackage bug tracker[0]; so, I've been working on a proposal. In this email I'd like to consolidate my mental notes for haskell-cafe and formulate a roadmap towards a more social Hackage. The most vital part is getting hackage-server <http://code.haskell.org/hackage-server/> to a state where it can be switched in place of hackage-scripts <http://darcs.haskell.org/hackage-scripts/>, and doing it properly, organizing the code so it can be extended painlessly in the future. Duncan Coutts, Antoine Latter, and others have done some great work on it in the past few years. I've been using Haskell for 1.33 of those years. I think I could become fluent in the codebases after a week of dedicated study, although even the hackage-server and hackage-scripts repositories don't include some components such as the current build report script. For putting the 2.0 in Hackage 2.0, any interface changes should help the library users and the library writers/uploaders without hurting either of them. Hackage should contain more of the right kind of information. Statistics help everyone, and they're a pretty good gauge on the direction of Hackage as a whole. Package popularity contents are one form of this. Reverse dependencies and even dependency graphs[1] are great, if I can integrate and expand Roel van Dijk's work[2]. There should also be some space on package pages, or on pages a link away from them, for users to contribute information and suggestions. Coders can explain why or why not the package met their needs, as a sort of informal bug/enhancement tracking service. Another helpful flavor of information is package relationships beyond dependencies: 'Deprecated in favor of Foo', 'a fork of Foo', or 'does blah instead of Foo's plugh functionality'. This will help people find the 'right' package among look-alikes. There could also be links to illustrative usage examples for getting started. Happstack's state management will be a good match for updating and serving this information in real time. There's also a need for a more interactive form of package documentation, but this should strengthen relationships with existing tools like Haddock and Cabal, not bypass the tools. For example, adding a changelog[3] or making Haddock's declaration-by-declaration commentary more wiki-like[4]. Changelogs seem to be within the scope of Hackage 2.0, integrating with Cabal; Haddock wikification might not be, perhaps deserving a separate student-summer session of its own. These can improve the package page and documentation subtrees. More generally, how can library users find the package they want? Categories themselves are great, but a tag system could identify and group specific package functionality. There could be sorting by ratings and reviews (4/5 lambdas!). Metadata searches, like those Sascha Böhme implemented in SoC 2007[5], could be integrated. It's not always obvious which ideas will help and which won't see good returns, which makes it all the more important to bring hackage-server to a state where future extensions can be easily written, submitted and deployed. That's the goal here. On the technical side, I realize I'd need to spend a not-insignificant amount of time on a user account system, dealing with authentication and related issues. One additional bit of functionality to manage is the hackage build system, which is used to ensure that packages build and to generate documentation. When building depends on FFI or OS-specific bindings, specific versions of other packages, compiler choice or compiler version choice, including language extensions, this is not trivial. One of two good routes is running cabal server-side to generate build reports and alleviate the miscompiling a smidge. Given that cabal install dependency calculation seems to be up in the air still, the current Setup-running script might end up staying for the moment, with some basic integrity checking (no cycles or other impossible dependency scenarios). The other not-mutually-exclusive approach is accepting failed build reports from users as a web service[6] to generate a matrix of the platforms that seem to encounter the most trouble. Ultimately, it's important that I, or whoever ends up doing the project, plans for it to benefit you guys. What do you think? —Matt Gruen PS: how do you feel about augmenting the .cabal format to provide more information for Hackage? [0] Active Tickets by Component, scroll down to HackageDB. http://hackage.haskell.org/trac/hackage/report/9?USER=anonymous&page=3 [1] Re: ANN: Reverse Dependencies in Hackage (demo). http://www.haskell.org/pipermail/haskell-cafe/2009-October/067847.html [2] Show reverse dependencies. Includes a patch for hackage-scripts. http://hackage.haskell.org/trac/hackage/ticket/576 [3] Add changelog feature to hackagedb. http://hackage.haskell.org/trac/hackage/ticket/299 [4] Reddit comment. The other comments are good too. http://www.reddit.com/r/haskell/comments/8bylw/ask_haskell_reddit_how_can_w… [5] Hackage Web Interface, Doc-Browser. http://code.google.com/soc/2007/haskell/appinfo.html?csaid=D505A03B8B64C3BF [6] cabal-install should report build results to hackage server. http://hackage.haskell.org/trac/hackage/ticket/184

12 20

ANNOUNCE: darcs 2.4.1
by Reinier Lamers 13 Apr '10

13 Apr '10

Hi all, The darcs team would like to announce the immediate availability of darcs 2.4.1. This release fixes a number of issues that were found in darcs 2.4. The most important of these issues were that darcs did not work on Windows shares, and that darcs would not work if it was built with a wrong version of the mmap package. The easiest way to install darcs is using the Haskell Platform [1]. If you have installed the Haskell Platform or cabal-install, you can install this release by doing: $ cabal update $ cabal install --reinstall darcs Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.4.1.tar.gz and build it by hand as explained in the README file. What's New ---------- * Important changes in Darcs 2.4.1 * darcs works again on Windows network shares * missing documentation and test files have been added to the tarball * darcs will no longer give errors about a nonexistent file when compiled with the wrong mmap * moving files between directories can no longer break the directory index * darcs handles the case that someone uses 'remove -r' on an untracked directory * darcs ignores symlinks again, like all pre-2.4 releases * Bugs Fixed in Darcs 2.4.1 * 1645: ignore symlinks * 1750: uncover help text for 'darcs show pristine' * 1753: restrict mmap to version used by hashed-storage * 1754: fix issue458.sh on systems with xattrs * 1756: moving files between directories breaks index * 1757: add test files to distribution tarball * 1765: refuse to remove non-tracked directories recursively * 1767: send CRC erros to standard error Reporting bugs -------------- If you have an issue with darcs 2.4.1, you can report it via the web on http://bugs.darcs.net/ . You can also report bugs by email to bugs(a)darcs.net. Kind Regards, the darcs release manager, Reinier Lamers [1]: You can download the Haskell platform from http://hackage.haskell.org/platform/

1 0

dependent types
by Andrew U. Frank 13 Apr '10

13 Apr '10

in modeling real application we have often the case that the type of some object depends on a value. e.g. small_boat is a vessel with size less than a constant. big_boat is a vessel with a larger size. for example, many legal classifications are expressed in this form (e.g. car vs. truck) depending on the type, operations are applicable or not (e.g. road with restriction 'no trucks'). how could one model such situations in haskell? i assume there are several possibilities...

6 8

ANN: vcd-0.0.0
by Tom Hawkins 13 Apr '10

13 Apr '10

I uploaded a small library [1] for generating VCD files [2], which can be viewed with waveform tools like GTKWave [3]. Though VCD is commonly associated with Verilog simulation, at Eaton we use it to visualize vehicle data in realtime: data is pulled off the CAN bus, formated to VCD, then piped into GTKWave. Most operations are in the IO monad, but if there's a better way to do it, I'm open to suggestions. I hope to add a simple VCD parser to the library soon; again suggestions welcome. -Tom [1] http://hackage.haskell.org/package/vcd [2] http://en.wikipedia.org/wiki/Value_change_dump [3] http://en.wikipedia.org/wiki/GTKWave

1 0

mingw32_HOST_OS and friends
by gladstein＠gladstein.com 13 Apr '10

13 Apr '10

1 0

Cabal update problem
by Maciej Podgurski 12 Apr '10

12 Apr '10

Hi, after updating to cabal-install-0.8.0/Cabal-1.8.0.2 with GHC 6.10.4, I always get an error when updating the package list: > cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: premature end of compressed stream Is there a way to fix this without rebuilding from the latest darcs repo? Best wishes, Maciej

6 10