January 2009 - Haskell-Cafe

How outdated is Hugs?
by Rafael Gustavo da Cunha Pereira Pinto 11 Feb '09

11 Feb '09

Hi, I see Hugs last source code snapshot dates back to 2006. Was there any updates? Regards -- Rafael Gustavo da Cunha Pereira Pinto Electronic Engineer, MSc.

12 19

Does readFile "/proc/mounts" hang for you?
by David Fox 09 Feb '09

09 Feb '09

I posted a bug about this (http://hackage.haskell.org/trac/ghc/ticket/2971) but its so odd I had to ask here. Using ghc 6.10.1, both readFile "/proc/mounts" and Data.ByteString.Lazy.Char8.readFile "/proc/mounts" hang on an amd64 machine running Linux. Also, Data.ByteString.readFile "/proc/mounts" returns the empty string. Is this behavior present for others? On i386?

7 7

[ANN] Working with HLint from Emacs
by Alex Ott 08 Feb '09

08 Feb '09

Hello For Emacs users it could be interesting - I wrote small module for more comfortable work with HLint from Emacs. It has same functionality as compilation-mode - navigation between errors, etc. To use it, just add following code to emacs init file: (require 'hs-lint) (defun my-haskell-mode-hook () (local-set-key "\C-cl" 'hs-lint)) (add-hook 'haskell-mode-hook 'my-haskell-mode-hook) Module is available from http://xtalk.msk.su/~ott/common/emacs/hs-lint.el -- With best wishes, Alex Ott, MBA http://alexott.blogspot.com/ http://xtalk.msk.su/~ott/ http://alexott-ru.blogspot.com/

6 7

ANN: HLint 1.2
by Neil Mitchell 07 Feb '09

07 Feb '09

Hi, I am pleased to announce HLint version 1.2. HLint is a lint-like tool for Haskell that detects and suggests improvements for your code. HLint is compatible with most GHC extensions, and supports a wide variety of suggestions, and can be extended with additional user suggestions. To install: cabal update && cabal install hlint Web page: http://www-users.cs.york.ac.uk/~ndm/hlint/ Biggest new feature: List recursion suggestions. For example, running HLint over the GHC compiler now suggests things such as: Example.hs:3:1: Warning: Use foldr Found: seqList [] b = b seqList (x : xs) b = x `seq` seqList xs b Why not: seqList xs b = foldr seq b xs Example.hs:6:1: Warning: Use foldr Found: seqIds [] = () seqIds (id : ids) = seqId id `seq` seqIds ids Why not: seqIds ids = foldr (seq . seqId) () ids Example.hs:13:1: Warning: Use foldl Found: rev_app [] xs = xs rev_app (y : ys) xs = rev_app ys (y : xs) Why not: rev_app ys xs = foldl (flip (:)) xs ys HLint will automatically detect if you should have used a map, a foldr or a foldl and suggest how to change your code. In the GHC, darcs and Hoogle code bases there are no obvious map-like functions, which is a good sign :-) Changes from last time: * More GHC extensions supported - including record wild cards and fixes to a number of existing extensions. These changes are thanks to Niklas and the haskell-src-exts package. * Many infix operators are now correctly associated with the right priority. * All hints are now ignored, warnings or errors. Hopefully this should make it clearer what hints are most important. As part of this, the format for defining ignore files has changed completely - see the manual for the new format. * Lots of new hints have been added - many from users of HLint. * Many bugs have been fixed. Can any follow-up discussions please be directed to haskell-cafe@. All comments, questions, bug reports are welcome! Neil

13 33

1,000 packages, so let's build a few!
by Andrew Coppin 07 Feb '09

07 Feb '09

In celebration of Hackage reachin over 1,000 unique packages, I decided that I would re-visit the problem of attempting to build them on Windows. I began by removing all existing Haskellness from my PC. I now have a vanilla Windows XP (32-bit) system with Service Pack 3. So, let's see what we can do here... - Install GHC 6.10.1. As you'd expect, no issues here. - Now, let's install stream-fusion. First let me ch... woah! What the hell? OK, it seems that Google is temporarily "broken". (All websites show up as "this site may damange your computer".) Obviously this has nothing to do with Haskell, but it makes navigating Hackage moderately more tedious. Oh well, anyway, where was I? Ah yes, I already have the tarball for stream-fusion-0.1.1, but I see that the latest release is 0.1.2.1. (Unfortunately, there doesn't appear to be any way to determine what the difference is between the two versions...) - Right, I've got the tarball for stream-fusion. Now let's see if it will install... J:\Haskell\unpack> runhaskell Setup configure J:\Haskell\unpack> runhaskell Setup build J:\Haskell\unpack> runhaskell Setup install J:\Haskell\unpack> ghc-pkg list ...stream-fusion-0.1.2.1... OK, nothing much wrong with that then. :-D - Hmm, doesn't GHC 6.10.1 now come with Haddock included? I wonder if there's a way to ask Cabal to build the docs for me... [Grr! Google is still busted.] Ah, yes there is. OK, let's try this: J:\Haskell\unpack> runhaskell Setup haddock ... Data\Stream.hs:292:33: parse error on input `!' haddock: Failed to check module: Data.Stream Uh... OK. So I guess I *won't* build the docs for that one then. :-/ Oh well, maybe it's a one-off failure? Let's try some more packages... - Next up, let's try the excellent ansi-terminal package. Checking Hackage [again without Google] and I see that the tarball I've got is still the latest version (0.5.0). Let's see what happens now... J:\Haskell\unpack> runhaskell Setup configure J:\Haskell\unpack> runhaskell Setup build J:\Haskell\unpack> runhaskell Setup haddock J:\Haskell\unpack> runhaskell Setup install J:\Haskell\unpack> ghc-pkg list ...ansi-terminal-0.5.0... Well, that installed OK. And look... it's given me a little folder full of Haddock documentation. How nice! Pitty it's burried 5 subfolders deep on the system drive with no hyperrefs to it... but I guess I could just bookmark the root folder or something? That'll work. (I.e., when I add more packages, it'll still be easy to navigate to their documentation this way.) - Now on to the ambiguously-named "binary" package. Again, I have a tarball for 0.4.2 but the latest is 0.4.4. (And, again, no indication of how this is different. But let's hope the difference is that it's fixed to work with GHC 6.10...) Configure, build, Haddock, install... no issues. That's refreshing. - OK, so what have we done? We've done stream-fusion, which is 100% Haskell. We've done ansi-terminal, which only links to standard Win32 headers [which, oddly, seem to come bundled with GHC]. And we've done binary, which (I think!) comes bundled with a few small snippets of C. Now let's try something harder... - Gtk2hs doesn't seem to want to work with GHC 6.10 yet; that's a pitty. It's a nice library. OTOH, how many Windows users have GTK+ installed? It's fairly uncommon. Fortunately you can just bundle the DLLs along with your app; unfortunately there's *a lot* of them, and they're quite large. And, obviously, you get a very non-native look & feel. Still, it *is* a nice library, and I'm sure at some point people will hassle Duncan to the point where an update appears. ;-) - A better choice, theoretically, should be wxHaskell. As I understand it, wxWidgets is supposed to look native. (Do you still have to bundle a DLL? Or is it statically linked in? Or...?) Oh well, I'd like to at least try it out and see how it works... Hmm, looks like you can obtain it via Cabal, or there's a special Windows build where you just run a BAT file and it registers everything for you. Let's try that first... "Click on the newly created wxhaskell-0.11.0\bin\wxhaskell-register.bat program to register the wxHaskell package. To uninstall, you can click on wxhaskell-0.11.0\bin\wxhaskell-unregister.bat and than remove the wxhaskell-0.11.0 directory." That sounds easy. Let's try it... 1 file(s) copied. 1 file(s) copied. 1 file(s) copied. - register packages 'ghc-pkg' is not recognized as an internal or external command, operable program or batch file. 'ghc-pkg' is not recognized as an internal or external command, operable program or batch file. error: Unable to register the package using "ghc-pkg". Maybe you have an incompatible version of ghc installed? Press any key to continue . . . Uh... what? OK, let's see if I can figure out what this batch file is trying to do... Er... wow. o_O Alright, there's no way I'm going to figure this out. I can't even tell where it's trying to install to or anything. Hmm. Well, it looks like it's all compiled and it's just trying to copy a few files and register them with GHC. That's probably a lot simpler than trying to actually compile from source using Cabal. I don't know what's confusing it, but maybe somebody in HCafe will know? I'm going to leave this one for now... - Another exciting package is the Haskell binding for libSDL. I am just *dying* to start doing some sound coding with Haskell, so I'm very interested in getting this one to work. Last time I tried it failed miserably, but let's see what we get this time around... Hmm, OK. Well let me see now... There's a project on Sourceforge called "hSDL" which seems to be dated Apr 2005. Then there's a thing called "hsSDL" on somebody's website dated around Feb 2008. And finally on Hackage itself there's a "SDL-0.5.4" dated Apr 2008. Oh... goodie. Well, let's go with the latest date, shall we? OK, download SDL-0.5.4. Unpack. Let's see if there's any useful documentation in here... Ah, "Win32". What does that contain? Mmm, looks useful. OK, let's follow these instructions and see what I get... Need to grab libSDL... Downloaded SDL-devel-1.2.13-mingw32.tar.gz. Unpacked it to C:\SDL. OK, now what? Ooo, manually edit the Cabal file... goodie! OK, well this shouldn't be too hard... Right, now... configure... That looked OK... build... Preprocessing library SDL-0.5.4... Graphics\UI\SDL\General.hsc:1:17: SDL.h: No such file or directory Graphics\UI\SDL\General.hsc: In function `main': Graphics\UI\SDL\General.hsc:57: error: `SDL_INIT_TIMER' undeclared (first use in this function) Graphics\UI\SDL\General.hsc:57: error: (Each undeclared identifier is reported o nly once Graphics\UI\SDL\General.hsc:57: error: for each function it appears in.) Graphics\UI\SDL\General.hsc:58: error: `SDL_INIT_AUDIO' undeclared (first use in this function) Graphics\UI\SDL\General.hsc:59: error: `SDL_INIT_VIDEO' undeclared (first use in this function) Graphics\UI\SDL\General.hsc:60: error: `SDL_INIT_CDROM' undeclared (first use in ...etc... OK, that's fantastic. Now what? So where *is* SDL.H then? Ah, it's in C:\SDL\include\SDL. Maybe if I adjust the Cabal path... configure... build... OMG! It looks like that might even have worked... Haddock... install... Well, well! That seems to have worked! Right, are there any example programs with this puppy?... No, there aren't. Apparently. Well that keeps things interesting... OK, well it looks like Graphcs.UI.SDL.CPUInfo is trivial, so let's see if I can compile a short program that calls it. Right, well it compiles. Does it run? ...no. It can't find SDL.dll. Presumably if I insert that into my search path somewhere... woo! It works! :-D Right, well. I guess if I can find some nontrivial examples from somewhere, I can try this thing out properly. (Looking at the API documentation, it's not very obvious how to do anything with it...) - OK, well I guess this message is long enough already. I notice there's a brand new version of HDBC out, so tomorrow I'm going to attempt to finally make a Haskell program actually talk to a database. ;-) TO BE CONTINUED...

11 25

ANN: diagrams 0.2
by Brent Yorgey 06 Feb '09

06 Feb '09

I am very pleased to announce the 0.2 release of the diagrams package, an embedded domain-specific language for creating simple graphics in a compositional style. This release includes a number of significant new features, including: * support for arbitrary straight and curved paths * more shape primitives, including polygons and rounded rectangles * support for rendering text * PNG, PDF, PS, and SVG output * built-in color support replaced with external dependence on the feature-rich colour library and many more! More information, examples, and installation instructions can be found at http://code.haskell.org/diagrams. More features are planned for future releases, so contributions and suggestions are welcome. (Please note: since diagrams depends on the Cairo library, which has unfortunately not been Cabalized, you cannot install the diagrams library with cabal-install, unless you already have the cairo package installed. See the above website for instructions.) A special thanks to Dougal Stanton for his contributions to the library and help in preparing this release. -Brent

6 9

Open unqualified imports
by eyal.lotem＠gmail.com 04 Feb '09

04 Feb '09

Hi, I would like to suggest a change to Haskell prime's handling of imports. First, let me define a few terms: Qualified import: import qualified Data.Map [as Map] Closed-unqualified import: import Data.Map(Map, lookup) Open-unqualified import: import Data.Map I believe that the last type, open-unqualified is a really bad idea, and should be discouraged or even disallowed. It should definitely not be the default, like it is today. These are my reasons: A) Most importantly, reading code that has even a few open unqualified imports makes deciphering where names are coming from really difficult. The other two forms make it really easy. Code is read more often than it is written -- lets optimize for the reading case. B) Code that has open unqualified imports may break when new symbols are added to the libraries its importing. This means that libraries cannot even be considered backwards compatible if they retain semantics, but add new exported names. C) In my experience, Haskell modules can map their semantics to standard type-classes such as Monoid, Functor, Applicative, etc. This means that many Haskell modules can do without exporting many names. Sometimes, they can export no names at all (Only instances). This means that closed-unqualified imports often do just fine. When there are many exported names, qualified imports are good. ----------------- I think currently many modules are designed to be imported unqualified, and this is unfortunate. Haskell' libraries can fix this. For example, the various Monadic counterparts such as mapM, replicateM, etc could do without the "M" in their names, and one could use: import qualified Control.Monad as M M.for M.map and so on. Additionally, I think there are some strong sentiments against the choice of the function-composition dot as the qualified module name lookup symbol. It discourages people from using qualified imports. Some other symbol ought to be used, but its not clear which symbol is free. Perhaps if unicode operators are allowed, then function composition can move to the "right" symbol. I believe qualified imports should probably have this syntax: import Control.Monad as M Closed-qualified imports can remain in the same syntax. Open-qualified imports should probably be discouraged with a syntax like: import unqualified Control.Monad And symbol clashes with these should probably just always choose the overriding name. Additionally, it would be nice if open unqualified imported were considered quick&dirty enough for -Wall to warn that they generate name clashes or are more difficult to read, to further discourage them. Eyal

8 9

Why binding to existing widget toolkits doesn't make any sense
by Achim Schneider 03 Feb '09

03 Feb '09

Hacking away on bindings to (http://libagar.org) specifically (http://libagar.org/mdoc.cgi?man=AG_Object.3) I was suddenly swept away by a general crisis of purpose: I was spending time on figuring out how to create agar objects, implemented in Haskell, on the fly, to enable me to write a high-level interface, instead of spending time on designing The FRUI API To Obsolete Them All. The reason for this are means of composability: What use is a nice interface to a button and an isomorphic interface to a textbox, if I can't compose them properly? Users might want to use standard widgets in indefinitely many combinations of type, with an equal amount of distinct wirings and external interfaces. As some of you might have noticed [1][2], constructing foreign objects is painful, specifying custom classes even more so... in case it's not infeasible hard to support in the first place. In agar's case it's certainly possible, by the virtue of being implemented in plain C. So we _could_ expose the whole generality of a TK's means of composing to the user. Which is most likely not what he wants, he wants to use the whole generality of Haskell to compose UI's. In Agar's case, the user won't care much about generating N checkboxes for a bitfield integer, he'd rather use [Event Bool]. Summing up, there's a lot of plumbing to be done, in the end still amounting to a lot of dead, unused code in the TK, BECAUSE TOOLKITS ARE DESIGNED TO BE USED IN THE LANGUAGE THEY WERE BLEEDING WRITTEN IN AND PROVIDE CUSTOM ABSTRACTIONS TAILORED TO THAT LANGUAGE. This is basically the Saphir-Worph hypothesis adapted to programs. So what's left of those TK's if we don't use their abstractions and replace them with Haskell? Drawing and layouting, that's what's left[3]. Both, IMNSHO, do not justify carrying around bloaty external dependencies, they're too trivial. They certainly don't justify using unsafePerformIO to hide foreign side effects and the headaches associated with it. So, if you don't mind, I'm going to stop trying to fit cubes into round holes and gonna use reactive and fieldtrip[4] to do things. [1]http://softbase.org/hqk/qoo/qoo.pdf [2]http://haskell.org/gtk2hs/docs/devel/System-Glib-GObject.html#v%3AmakeNew… [3]Somewhat disregarding using OS widgets, but that's unimportant since native look+feel is vastly overrated. I've got enough asbestos to defend that against alt.politics. [4]Gotta get rid of glut, though. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited.

21 71

type and data constructors in CT
by Gregg Reynolds 03 Feb '09

03 Feb '09

Hi, I think I've finally figured out what a monad is, but there's one thing I haven't seen addressed in category theory stuff I've found online. That is the relation between type constructors and data constructors. As I understand it, a type constructor Tcon a is basically the object component of a functor T that maps one Haskell type to another. Haskell types are construed as the objects of category "HaskellType". I think that's a pretty straightforward interpretation of the CT definition of functor. But a data constructor Dcon a is an /element/ mapping taking elements (values) of one type to elements of another type. So it too can be construed as a functor, if each type itself is construed as a category. So this gives us two functors, but they operate on different things, and I don't see how to get from one to the other in CT terms. Or rather, they're obviously related, but I don't see how to express that relation formally. If somebody could point me in the right direction I'd be grateful. Might even write a tutorial. Can't have too many of those. Thanks, Gregg

5 13

Cabal and more than one version
by Jason Dusek 03 Feb '09

03 Feb '09

I'd like to be able to do something like: if (template-haskell < 2.3) cpp-options: -D TH_THE_YOUNGER else cpp-options: -D TH_THE_ELDER I guess this kind of thing is not possible at present? -- _jsn

3 9