- Haskell-Cafe - Haskell.org

ANNOUNCE: Blueprint 0.1 -- PREVIEW
by Gregory Crosswhite 06 Dec '09

06 Dec '09

I earlier posted to this list asking for help in getting Cabal to play with a Fortran compiler. When it turned out that there was no answer to this, I of course did the obvious thing --- I wrote my own build system. :-) It already boasts the following features: * Fully self-hosting --- can both build and install itself. * Implicitly detects and tracks module dependencies. * Builds in parallel as much as possible. * Can scan through a source directory to add all files, saving the trouble of adding them manually. * Supports compiling C and Fortran sources in addition to Haskell sources, and linking everything together. * Utilizes a “tool” system to make it easy to extend its functionality, such as by adding a new language. * Flexible configuration system: tool options (e.g., path to the Fortran compiler) can be detected automatically, set in a configuration file, or specified on the command line. * Provides help messages both to list the targets and to explain the configuration command-line options. * Does not terminate at the first error, but instead tries to do as much as possible and then report all errors. (This is a general philosophy that holds both for the build, the configuration, etc.) * Easily supports multiple targets that can depend on the results from other targets. * Automatically resolves package dependencies, as read from .cabal file. Detects when a module is not in any known dependency, and reports an error that also lists all packages that export this module. What separates this system apart from others is that it uses Haskell’s built-in laziness to handle dependency ordering and parallelism. That is, one expresses the desired build result as a function of the input sources; when the result is demanded, it causes Haskell to go through and execute on-demand all of the necessary build steps. To get parallelism, just tell GHC to use multiple threads with the “+RTS -N# -RTS” option, where # is the number of threads. (All that I had to do to get this to work was put parLists in a couple of places.) This is a big win for me because it means that I get the correct behavior without having to write and test my own complicated graph data structure for tracking the dependencies between build steps. The philosophy of building up a big calculation of which only parts need be lazily demanded can be extended further to the build phases, which I call “targets”. For example, the first line of the code defining the build target is: build = configure >>= \configuration -> ... This demands the configuration target, and then uses the result in the build. So when you run “./Setup configure”, you only demand that Setup compute the value of “configure”, but when you run “./Setup build” you demand both “build” and also “configure”. All of the errors that are reported are “composable” in the sense that they can be combined into a new error message that leaves nothing out and also has no duplicates. As much as possible the system tries not to stop until it has nothing else that it can do, allowing it to uncover as many errors as possible and then compose them into a single message. I have posted Blueprint to Hackage so that people can see what I have done and possibly play with it. I hope to eventually document it and add examples, but I figured it was better to release early and get it out there sooner rather than later so that people can see what I’ve done. Thus, at this point it should be considered a PREVIEW release, not even an alpha release. Having said that, within the domain of the functionality it implements it works well enough that I use it myself as the build system for a Physics simulation code that is a mixture of C, Haskell, and Fortran. To see what Blueprint looks like in action, take a look at Setup.hs. For example, Setup can either build a library (“build” target) or it can build itself (“bootstrap” target); it is smart enough to use different flags and directories in the two cases so that there ends up being in essence two parallel builds. Setup also has a lot of targets: configure, reconfigure (delete cached configuration and then configure), build, rebuild (clean then build), clean, distclean, install, bootstrap (build itself rather than a library), haddock (documentation generation that does not work particularly well yet). Anyway, take a look if any of this sounds interesting to you, and let me know if you have any questions! - Greg PS: You're best bet for browsing through the sources is to use Leo (leo.sourceforge.net) since this makes it easier for you to see how everything is organized.

2 3

HP + Gtk2hs?
by Andrew Coppin 06 Dec '09

06 Dec '09

So I decided to try out the Haskell Platform instead of just installing GHC directly. To be honest, I didn't really notice much difference, except for the files being installed in a different place. But then, initially HP ~= GHC; presumably the plan is for it to grow as time goes on. Anyway, I'm sure you can all see where I'm going with this: Latest Gtk2hs binary for Windows doesn't seem to like the latest HP installation. A few things: - It is unclear to be which Gtk2hs binaries require which GHC version. Can we tabulate this information somewhere? - It is also unclear to me which HP versions contain what stuff. The HP page tells you all about the *current* HP version, and contains a link to a raw directory listing for the older versions. (I especially love the way the server truncates the filenames to just before where the version number starts. Very helpful. :-D ) Can we get propper descriptions for _all_ releases of HP? A table summarising the GHC version and major packages/versions in each release would be nice. - Any idea why the HP says "beta" on it? - Apart from HP providing GHC 6.10.4 while Gtk2hs currently requires 6.10.3, it appears that the Gtk2hs installer package doesn't like GHC being installed in a path with spaces. Apparently Gtk2hs has a bug tracker. (I only just discovered this, so perhaps it needs to be more prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers. (I emphasize "visible". Maybe they've seen this and they're working on it, but there's no visible indication of activity.) Gtk2hs is currently the *only* GUI binding that actually works on Windows. It's always been slightly frustrating that every time a new version of GHC comes out, us Windows users have to beg for somebody to build a new binary. (Linux users, on the other hand, can just download the sources and compile them with any compiler they like.) Presumably going forward Gtk2hs will synchronise to the (less frequent) HP releases rather than the individual GHC releases, so many this particular frustration will be reduced. (It would be even less frustrating if Gtk2hs was *in* HP, but I gather this won't ever happen.) Of course, being able to actually build C bindings on Windows would be even better, but this is apparently infeasible... :-( That being the case, I'll settle for just a little bit more documentation.

6 10

universal binary version of Haskell Platform?
by Benjamin L.Russell 06 Dec '09

06 Dec '09

Recently, in changing my work schedule to work mainly from home, I switched from mainly using a work Wintel machine running Windows XP Professional, Service Pack 3, to mainly using my home PowerPC G4 PowerBook Macintosh, currently upgraded to Mac OS X 10.5.8 Leopard. However, to my surprise, there does not seem to be a version of the Haskell Platform that runs natively on my current OS. Does anybody know where to find a universal binary version of the Haskell Platform, or at least of GHC 6.10.4? Otherwise, I'm stuck without a native version. -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

4 3

Re: Optimizing Parsec 3 -- was: Wiki software?
by Howard B. Golden 05 Dec '09

05 Dec '09

On Friday December 4, 2009, John MacFarlane wrote: > I used criterion to compare pandoc compiled with parsec2 to > pandoc compiled with your version of parsec3. (The benchmark > is converting testsuite.txt from markdown to HTML.) The difference > was minor: > > parsec2: > mean: 67.66576 ms, lb 67.56722 ms, ub 67.88983 ms, ci 0.950 > std dev: 722.3878 us, lb 323.0343 us, ub 1.356013 ms, ci 0.950 > > parsec3: > mean: 68.20847 ms, lb 68.16387 ms, ub 68.26284 ms, ci 0.950 > std dev: 252.7773 us, lb 204.5512 us, ub 325.2424 us, ci 0.950 > > So, once you release the new parsec3, I am prepared to remove the > "parsec < 3" restriction from the libraries I maintain: pandoc, > highlighting-kate, filestore, gitit, and yst. I don't know what the performance of the current parsec3 is compared to parsec2. It would be helpful if you could run your benchmark for that also and include it. If the only issue is performance, I respectfully request that you remove the parsec < 3 requirement even before the new version of parsec3 is released. Thank you. Howard

2 1

Avoiding undecidables
by Michael Snoyman 05 Dec '09

05 Dec '09

Hi all, Well, I've got two problems which both want to be solved with undecidable and overlapping instances. Obviously, I'd like to try and avoid them. For the record, the problems have to do with the control-monad-failure and convertible packages. The code below *should* make clear what I'm trying to accomplish: -- failure should not be limited to just monads, so... class Failure e f where failure :: e -> f v class (Functor f, Failure e f) => FunctorFailure e f instance (Functor f, Failure e f) => FunctorFailure e f -- undecidable, overlaps class (Applicative f, Failure e f) => ApplicativeFailure e f instance (Applicative f, Failure e f) => ApplicativeFailure e f -- undecidable, overlaps class (Monad f, Failure e f) => MonadFailure e f instance (Monad f, Failure e f) => MonadFailure e f -- undecidable, overlaps And now the convertible issue. I want two type classes: Convert for anything which *might* be convertible, but might not. For example, sometimes a String can be converted to an Int (like the string "5"), but sometimes it will fail (like "five"). TotalConvert is when something *is* convertible, such as Int to String (simply the show function). Thus the following: class Convert x y where convert :: x -> Maybe y class Convert x y => TotalConvert x y where totalConvert :: x -> y instance TotalConvert x y => Convert x y where -- Boom! convert = Just . totalConvert Any ideas are most welcome. Both of these seem like cases where the compiler could do some DWIMery, but isn't. Michael

3 3

Re: [Haskell-cafe] HP + Gtk2hs?
by Andrew Coppin 05 Dec '09

05 Dec '09

M Xyz wrote: > > > > - Apart from HP providing GHC 6.10.4 while Gtk2hs currently > requires 6.10.3, it appears that the Gtk2hs installer package > doesn't like GHC being installed in a path with spaces. Apparently > Gtk2hs has a bug tracker. (I only just discovered this, so perhaps > it needs to be more prominent?) Somebody pointed out this bug 6 > months ago. Somebody else posted a potential fix a month ago. > There is no visible activity from the developers. (I emphasize > "visible". Maybe they've seen this and they're working on it, but > there's no visible indication of activity.) > > Thank you so much for this post. I tried to install Gtk2hs yesterday > to play with > its Cairo bindings and I hit the "Setup found what appears to be a > non-working installation of GHC" brickwall. I found a closed ticket > about this problem: http://hackage.haskell.org/trac/gtk2hs/ticket/1117 > I posted this issue on the Gtk2hs-devel mailing list and got a > response today: > http://sourceforge.net/mailarchive/forum.php?thread_name=EF0EE62B-259C-4F62… > > I don't think I have the will to uninstall the Haskell Platform and > everything I've set up just to install in a path with no spaces. :) > > My information is from here: http://hackage.haskell.org/trac/gtk2hs/ticket/1165 In case it makes any difference to you. :-)

1 0

Re: [Haskell-cafe] HP + Gtk2hs?
by M Xyz 05 Dec '09

05 Dec '09

- Apart from HP providing GHC 6.10.4 while Gtk2hs currently requires 6.10.3, it appears that the Gtk2hs installer package doesn't like GHC being installed in a path with spaces. Apparently Gtk2hs has a bug tracker. (I only just discovered this, so perhaps it needs to be more prominent?) Somebody pointed out this bug 6 months ago. Somebody else posted a potential fix a month ago. There is no visible activity from the developers. (I emphasize "visible". Maybe they've seen this and they're working on it, but there's no visible indication of activity.) Thank you so much for this post. I tried to install Gtk2hs yesterday to play with its Cairo bindings and I hit the "Setup found what appears to be a non-working installation of GHC" brickwall. I found a closed ticket about this problem: http://hackage.haskell.org/trac/gtk2hs/ticket/1117 I posted this issue on the Gtk2hs-devel mailing list and got a response today: http://sourceforge.net/mailarchive/forum.php?thread_name=EF0EE62B-259C-4F62… I don't think I have the will to uninstall the Haskell Platform and everything I've set up just to install in a path with no spaces. :)

1 0

Finding HP
by Andrew Coppin 05 Dec '09

05 Dec '09

Today I was setting up a my new, and I wanted to put Haskell on it. Rather than download GHC itself, I decided to install the Haskell Platform instead, just to see what it's like. Much to my surprise, I couldn't actually find any reference to its existence anywhere from the haskell.org home page, and I eventually had to run a search to find it. Subsequently, I realise [as somebody will no doubt point out] that the link is actually there, on the front page, right next to GHC, Hugs, et al. My suggestion is that if we really want people to grab the HP rather than download GHC directly, maybe we could make the link slightly more prominent? It also wouldn't hurt to mention it from the "Implementations" page, and maybe the GHC homepage? Just a suggestion...

11 15

Wikipedia article
by Simon Marlow 05 Dec '09

05 Dec '09

As noted before, the Wikipedia article for Haskell is a disorganised mess. http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 earlier this year, dons suggested reorganising it and posted a template on the Haskell wiki: http://haskell.org/haskellwiki/WikipediaArticleDesign I've made a start on a new version of the page: http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%… I've kept most of the existing information, but reorganised it more or less according to Don's template, and I filled out the overview section. Also I fixed numerous things, but the page still has a long way to go Does anyone mind if I spam the existing Haskell article with this new one, or do people think we should continue editing the sandbox version until it's in better shape? Cheers, Simon

6 9

From function over expression (+, *) derive function over expression (+)
by Radek Micek 05 Dec '09

05 Dec '09

Hello. I have two types for expression: data Expr = Add Expr Expr | Mul Expr Expr | Const Int data AExpr = AAdd AExpr AExpr | AConst Int The first one supports addition and multiplication and the second only addition. I can write a function to simplify the first expression: simplify :: Expr -> Expr simplify = {- replaces: "a*1" and "1*a" by "a", "a+0" and "0+a" by a -} And I would like to use the function simplify for the second type AExpr. What can I do is to convert AExpr to Expr, simplify it and convert it back. But I don't like this solution because conversions take some time. I would prefer following: I say to the compiler that AAdd is like Add and AConst is like Const and the compiler derives function asimplify for AExpr. Is it possible to do this? In fact I want to have two distinct types where one is "extension" of the second (Expr is extension of AExpr) and I want to define a function for the extended type (Expr) and use it for the original type (AExpr). I assume that the function won't introduce Mul to the expression which had no Mul. Thanks in advance Radek Micek

6 9