June 2006 - Haskell-Cafe

Re: Haskell-Cafe Digest, Vol 34, Issue 45
by Jason Dagit 28 Jun '06

28 Jun '06

On 6/27/06, Jeremy O'Donoghue <jeremy.odonoghue(a)gmail.com> wrote: > Hi Jason. > > My $0.02 > > On 27/06/06, haskell-cafe-request(a)haskell.org > <haskell-cafe-request(a)haskell.org> wrote: > > ---------- Forwarded message ---------- > > From: "Jason Dagit" <dagit(a)eecs.oregonstate.edu> > > > Requirements: > > Okay, so now that you know why I'm here, let me give you an idea of > > what my *ideal* GUI library would be for this project (roughly in > > order of importance): > > 1) Doesn't require the end user to install anything (no dependencies) > > 2) Looks and feels like windows > > 3) Robust (or mature) > > 4) A pleasure to program (boo @ swing) > > 5) ?? > > > > I don't really know the landscape, but this is my (uneducated) idea of > > my options: > > A) wxWidgets > > B) gtk2hs > > C) win32 api > > D) write the gui in C or C++ and use the FFI to invoke it > > E) write the gui in scala or java and use FFI + JNI to invoke it > > F) ?? you tell me > > > > I think (although I have yet to verify) that (A) satisfies #1-4, but > > (B) doesn't satisfy #1. Is this true? I tried to install wxHaskell > > but it turned out to be a real pain. I'm using visual haskell so that > > I have COM support (I need the version of H/Direct that ships with > > VisualHaskell and VisuallHaskell only ships with ghc 6.5) and that > > means I have to compile the less mainstream haskell libraries myself. > > I have yet to successfully install wxHaskell on my dev machine at > > work. > > I've developed a couple of projects with wxHaskell, along with a > couple using the lablGtk2 library for Ocaml - in fact, the whole > clunkiness and lack of Windows and (especially) Mac native feel of GTK > on non-Linux platforms is a large part of what brought me to Haskell > :-) > > My applications are mainly for internal use at my workplace, and come > with Windows installers (I use Inno setup with wxHaskell - never > managed to make it work with GTK2, so these applications were > delivered as zip files which just had to be unzipped in a certain > place). Do you have any advice about using Inno with haskell? Have you tried wix at all? http://sourceforge.net/projects/wix/ Maybe you have a developer blog I could read? > To distribute wxHaskell applications you need only two DLLs and an > executable. All can be in the same directory. I think this covers 1) Yes, I would say that's almost ideal. (Ideally the user wouldn't even have to install my progam it would 'just work' ;) > Look and feel is Windows native. As an added bonus (for me, at least) > it also looks native on Mac and Linux. That's 2) Yes, I've used wxPython in the past very successfully. It's fast, easy to use, tends to look right. (in my narrow opinion) > wxHaskell is fairly robust, but you need to be aware that it does not > have complete coverage of the wxWindows library. I have found layout > behaviour to be incomprehensible at times (although I found this to be > somewhat true of the native wxWindows sizers on which layout is > built). Some of the more exotic widgets (Scintilla, wxGrid) are either > not wrapped, or the wrapping is incomplete. I have not succeeded, in > the general case, in getting sash wiondows to work as I would like > them to (it's possible for some limiting cases, but that is not enough > for my needs) Hmm...Yes I've fought extensively with the layout managers for Java that come with the Net Beans IDE. I think using a layout manager is a great idea, but then I'll spend several hours fighting with getting just one screen to layout correctly and never want to use layout managers again. Perhaps I'm just dense, but the Matisse gui builder in Net Beans is really frustrating for me. > My impression, sadly, is that little development now goes on on > wxHaskell. The last compiled binaries available from the website are > over a year old now and, as you've already discovered, it's really > quite difficult to get wxHaskell to compile on Windows. For what it's > worth, I gave up on 2.6.x and reverted to 2.4.2, which compiled > cleanly for me. I took a hint here and downloaded 2.4.2, followed the instructions to the letter and got things almost working. It seems that I had spaces in my paths. VisualHaskell installed to: C:\Program Files\Visual Haskell When I came to the step of compiling wxHaskell I needed to run configure with these options: ./configure --libdir=C:/Progra~1/Visual~1 The two important things here are: 1) You must use the forward slash and 2) you cannot use spaces. After it installed I started getting panics from 'ghc -package wx': http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-October/005632.h… And I found a solution here: http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-October/005639.h… Next I found that I needed to add C:\Program Files\Visual Haskell to my path so that the wxHaskell dlls could be located by windows. Now I'm at the point where I can compile and run wxHaskell programs (yay!). > > Because of the appearance that it's withering on the vine, I would be > reluctant to recommend wxHaskell. However, despite the gripes above, I > think it's a superb piece of work. I have managed to produce some very > high performance applications with it - users assumed that I had > written in hand-optimized C (FastPackedStrings also had a big hand in > the performance). If the project were better documented, I really > believe that there's a chance that the project would take off. As an > example, I easily have the knowledge of C/C++ needed to contribute, > and the Haskell is getting there, but the (lack of) documentation > makes it hard for the end user at times - let alone the wannabe > developer. When I used wxPython I was often referencing the C++ docs and I didn't mind as I'm reasonably fluent in C++. So (hopefully) this will not slow me down when using wxHaskell. > wxHaskell programming is something of a mix of Haskell idioms (layout, > in particular) and C style imperative programming (in IO monad). In > some respects the UI code looks quite similar to wxPython, but at > least you get Haskell goodness for everything else. This is a big > plus. This is something I'm looking forward to. A little bit of not-as-pretty Haskell with lots of typical Haskell to support it. I think it will make my project fun to work on as well as giving me certain bonuses in the software engineering department (go referential transparency!). [snipped testimonials about gtk2hs] Thanks for the info about gtk2hs. I feel like GTK is great and I would gladly use it on an open source project but I think given my target audience and my requirements it's not right for this project. > > I can't really comment on your other potential solutions. Hopefully I won't need them now :) Thanks, this was very helpful, Jason

1 0

Re: Haskell-Cafe Digest, Vol 34, Issue 45
by Jeremy O'Donoghue 28 Jun '06

28 Jun '06

Hi Jason. My $0.02 On 27/06/06, haskell-cafe-request(a)haskell.org <haskell-cafe-request(a)haskell.org> wrote: > ---------- Forwarded message ---------- > From: "Jason Dagit" <dagit(a)eecs.oregonstate.edu> > Requirements: > Okay, so now that you know why I'm here, let me give you an idea of > what my *ideal* GUI library would be for this project (roughly in > order of importance): > 1) Doesn't require the end user to install anything (no dependencies) > 2) Looks and feels like windows > 3) Robust (or mature) > 4) A pleasure to program (boo @ swing) > 5) ?? > > I don't really know the landscape, but this is my (uneducated) idea of > my options: > A) wxWidgets > B) gtk2hs > C) win32 api > D) write the gui in C or C++ and use the FFI to invoke it > E) write the gui in scala or java and use FFI + JNI to invoke it > F) ?? you tell me > > I think (although I have yet to verify) that (A) satisfies #1-4, but > (B) doesn't satisfy #1. Is this true? I tried to install wxHaskell > but it turned out to be a real pain. I'm using visual haskell so that > I have COM support (I need the version of H/Direct that ships with > VisualHaskell and VisuallHaskell only ships with ghc 6.5) and that > means I have to compile the less mainstream haskell libraries myself. > I have yet to successfully install wxHaskell on my dev machine at > work. I've developed a couple of projects with wxHaskell, along with a couple using the lablGtk2 library for Ocaml - in fact, the whole clunkiness and lack of Windows and (especially) Mac native feel of GTK on non-Linux platforms is a large part of what brought me to Haskell :-) My applications are mainly for internal use at my workplace, and come with Windows installers (I use Inno setup with wxHaskell - never managed to make it work with GTK2, so these applications were delivered as zip files which just had to be unzipped in a certain place). To distribute wxHaskell applications you need only two DLLs and an executable. All can be in the same directory. I think this covers 1) Look and feel is Windows native. As an added bonus (for me, at least) it also looks native on Mac and Linux. That's 2) wxHaskell is fairly robust, but you need to be aware that it does not have complete coverage of the wxWindows library. I have found layout behaviour to be incomprehensible at times (although I found this to be somewhat true of the native wxWindows sizers on which layout is built). Some of the more exotic widgets (Scintilla, wxGrid) are either not wrapped, or the wrapping is incomplete. I have not succeeded, in the general case, in getting sash wiondows to work as I would like them to (it's possible for some limiting cases, but that is not enough for my needs) My impression, sadly, is that little development now goes on on wxHaskell. The last compiled binaries available from the website are over a year old now and, as you've already discovered, it's really quite difficult to get wxHaskell to compile on Windows. For what it's worth, I gave up on 2.6.x and reverted to 2.4.2, which compiled cleanly for me. Because of the appearance that it's withering on the vine, I would be reluctant to recommend wxHaskell. However, despite the gripes above, I think it's a superb piece of work. I have managed to produce some very high performance applications with it - users assumed that I had written in hand-optimized C (FastPackedStrings also had a big hand in the performance). If the project were better documented, I really believe that there's a chance that the project would take off. As an example, I easily have the knowledge of C/C++ needed to contribute, and the Haskell is getting there, but the (lack of) documentation makes it hard for the end user at times - let alone the wannabe developer. In short, I'm not sure about 3). wxHaskell programming is something of a mix of Haskell idioms (layout, in particular) and C style imperative programming (in IO monad). In some respects the UI code looks quite similar to wxPython, but at least you get Haskell goodness for everything else. This is a big plus. Back in the day when I was using the Ocaml GTK2 binding, the following observations were true. I suspect they may be true of GTK2Hs (as they are mainly observations on GTK2 on Windows per se), but I am not certain. Installation of GTK2 on Windows is nothing short of revolting. It's a completely manual set of 'work out which DLL or library to download from where and install it in a suitable directory. Building from source is worse. I never managed to work out a small, sane set of DLLs which could just be packaged with the executable I was delivering. It may be possible, but I didn't manage it. That's a fail on 1), I suspect. Look and feel is adequate on Windows, for the most part. However, the file dialog, in particular, caused my users (mainly engineers, so pretty switched on, on the whole) no end of confusion, and was a major driver to my dropping Ocaml for this type of work. That's a failure on 2), at least for me. However, in its defence, GTK2 is stable and capable on Windows. I also have the impression that GTK2Hs is much more actively developed than wxHaskell, and this may be a good reason to choose it if what you are producing is a prototype which will not have wide distribution. I think you'd have to give GTK2Hs a good rating for 3). I can't really comment on your other potential solutions. Regards Jeremy

1 0

RE: [Haskell-cafe] A question about stack overflow
by voigt.16734551＠bloglines.com 27 Jun '06

27 Jun '06

--- Huazhi (Hank) Gong" <hankgong(a)nm.gist.ac.kr wrote: > Thank you very much for introducing tail recursion. > It's my first time to hear this. :) > However, I'm wondering whether every loop structure from C like language can > be translated to this kind of tail recursion? Yes, as discovered by John McCarthy almost 50 years ago in "Recursive functions of symbolic expressions and their computation by machine. Communications of the ACM, 3:184-195, 1960". Ciao, Janis Voigtlaender.

1 0

[GHC/Base.A_o] Error 1
by gaa＠cin.ufpe.br 27 Jun '06

27 Jun '06

Anyone can help me? I did some changes in the .mk and makefile files in order to integrate it with the Haskell.NET code generator but when I try to compile the following error appears: ../../ghc/compiler/ghc-inplace -H32m -O -W -fno-warn-unused-matches > -fwarn-unuse > d-imports -fglasgow-exts -cpp -Iinclude -#include HsBase.h -Icbits/regex > -funbox > -strict-fields -package-name base -O -dcore-lint -W > -fno-warn-unused-matches -fw > arn-unused-imports -fglasgow-exts -keep-msil-files -fvia-il -hisuf A_hi > -hcsuf > A_hc -osuf A_o -fvia-il -keep-msil-file -c GHC/Base.lhs -o GHC/Base.A_o > -ohi > GHC/Base.A_hi > GHC/Base.lhs:296: parse error on input `.' > make[3]: *** [GHC/Base.A_o] Error 1 > make[2]: *** [all] Error 1 > make[1]: *** [all] Error 1 > make[1]: Leaving directory `/cygdrive/c/Guilherme/ghc-6.2.2/libraries' > make: *** [build] Error 1 > > > > Thanks, Guilherme A. Avelino

2 1

Win32 GUI bindings
by Jason Dagit 27 Jun '06

27 Jun '06

I'm looking for recommendations (testimonials?) for GUI libraries for haskell (ghc 6.5) on the win32 platform that meet my requirements below. But first, I try to motivate my question. Bit of background: I work at a smallish software company and I've been given a project where I'm supposed to create a prototype which will later be scraped and a new version will be written that is part of our main product. The prototype will only ever run on windows and it will be distributed to customers for a year or two before it is assimilated. I've used python a bit to prototype the prototype and figure out some of the basics. I'll need a small GUI (maybe one or two dialogs), an XML library, a few small parsers and COM support. I was going to put Haskell back on the shelf and use either python or scala for this project because of the COM requirement but just today I made a major breakthrough with H/Direct and it looks like Haskell is back in the running. So far I plan to use HaXml, parsec and H/Direct but I still need some way to create a gui. This project is fairly representative of all the work we do at my company so I feel if I find a good solution this time it's probably what I'll focus on using in the future. That's part of the reason I'm trying out python, Haskell and scala. (Perhaps the real reason is just that I like playing with languages ;). Requirements: Okay, so now that you know why I'm here, let me give you an idea of what my *ideal* GUI library would be for this project (roughly in order of importance): 1) Doesn't require the end user to install anything (no dependencies) 2) Looks and feels like windows 3) Robust (or mature) 4) A pleasure to program (boo @ swing) 5) ?? I don't really know the landscape, but this is my (uneducated) idea of my options: A) wxWidgets B) gtk2hs C) win32 api D) write the gui in C or C++ and use the FFI to invoke it E) write the gui in scala or java and use FFI + JNI to invoke it F) ?? you tell me I think (although I have yet to verify) that (A) satisfies #1-4, but (B) doesn't satisfy #1. Is this true? I tried to install wxHaskell but it turned out to be a real pain. I'm using visual haskell so that I have COM support (I need the version of H/Direct that ships with VisualHaskell and VisuallHaskell only ships with ghc 6.5) and that means I have to compile the less mainstream haskell libraries myself. I have yet to successfully install wxHaskell on my dev machine at work. I think that (C) is going to violate #4 and maybe #3 depending on how much code I need to write to get the bare windows api to do what I want. Plus I doubt this makes sense for a long term solution. I think (D) makes less sense than (C) and I doubt it's a nice way to do things, I'm probably better off with (C). As for (E), why don't I just do the whole thing in scala if I'm requiring the GUI to be in scala? Advice? Thanks, Jason

3 3

Simple matrix
by Atila Romero 27 Jun '06

27 Jun '06

I made a very simple matrix module that implements matrix sum and multiplication. It does not require any especific type since it uses Num [[a]]. So instead of typing something like Matrix [[1,0],[0,2]] * Matrix [[1,2],[3,4]] you can just type [[1,0],[0,2]]*[[1,2],[3,4]] It needs -fglasgow-exts Atila module SimpleMatrix where instance Num a => Num [[a]] where fromInteger x = [[fromInteger x]] abs x = map (map abs) x (+) [ ] y = y (+) x [ ] = x (+) x y = zipWith (zipWith (+)) x y (*) x y = map (matrixXvector x) y where -- matrixXvector :: Num a => [[a]] -> [a] -> [[a]] matrixXvector m v = foldl vectorsum [] $ zipWith vectorXnumber m v -- vectorXnumber :: Num a => [a] -> a -> [a] vectorXnumber v n = map (n*) v -- vectorsum :: [a] -> [a] -> [a] vectorsum [] y = y vectorsum x [] = x vectorsum x y = zipWith (+) x y _______________________________________________________ Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! http://br.mobile.yahoo.com/mailalertas/

8 17

closures with side effects
by dkarapet 27 Jun '06

27 Jun '06

I have been trying to understand closures in haskell and how they relate to side effects. I have been looking around but all I find are trivial examples with no side effects. Please let me know if you know of any examples.

3 2

Scoped data declarations
by Christophe Poucet 26 Jun '06

26 Jun '06

Dear, Yesterday, while discussing with Cale and SamB on I suddenly came up with the crazy idea of scoped data declarations. After some brief discussion to check the validity, I finally came to the conclusion that they should be feasible. In addition, I don't think that they would require a high amount of changes in current compilers. Basically if you have something like: module Main where foo = let data Foo = Foo deriving Show in Foo\ main :: IO () main = print foo One can see this as having an extra hidden module that defines Foo but that does not export it. The only change that is then required is that while compiling Foo, the hidden-ness of Foo must be removed. For instance, if one were to load this into, say, ghci (this is fictive of course): # ghci Main.hs > :t foo foo :: Codeloc2.Foo There were initially some objections to this, because it is no longer feasible to actually write the type of the function foo. But if one looks at current GHC, this objection is already there: module A(foo) where data Foo = Foo deriving Show foo = Foo module Main where import A main = print foo As Excedrin then pointed out, importing this Main into ghci, gives foo :: Foo.Foo And this notation can not be written in Main either, because Foo is hidden in A. Therefore, I would like to note that scoped data declarations are just like hidden data-declarations with two extra requirements: 1) Generate source-location-based submodule names 2) Add an extra import rule for those hidden modules in the subexpressions of where the data-declaration is being originally defined. Comments are welcome, of course :) Cheers! Christophe (vincenz)

3 3

Re: [Haskell-cafe] Re: Functional progr., infinity, and the Universe
by voigt.16734551＠bloglines.com 26 Jun '06

26 Jun '06

--- paul.hudak(a)yale.edu wrote: Jerzy Karczmarczuk wrote: > > OK, I think that this subject matured enough to rest in peace... > > I would have to agree with that, although... Since the subject is not going to rest, why not also jump in? > Well, each partial list is finite. I think quite a few people would agree that a finite list is one ending in []. So 1:_|_ is a partial list, but not a finite one. 1:[] is a finite list. > But the limit of a chain IS the maximal element of the set of all > elements comprising the chain, since the LUB, in the case of a chain, is > unique, and thus we don't have to worry about choosing the "least" > element (i.e. it reduces to the upper bound, or maximal element). That doesn't quite make sense, IMHO. The chain _|_, 1:_|_, 1:1:_|_, 1:1:1:_|_, ... has the limit (or upper bound) "ones", but "ones" does not appear in the chain. An upper bound of a set may not appear in the set. But the maximal element of a set by definition ("element of") necessarily is in the set. So you cannot use the two notions interchangably. BTW, if the limit of a chain would always appear in the chain (by virtue of being the maximal element of the set of all elements comprising the chain), then every chain would be stationary eventually. That would quite simplify denotational semantics, wouldn't it? > So I'd say that Brian has at least come close to discovering God :-) And come to the conclusion, in a later mail, that both: A. "the list [0,1,2,3,4,5,..] is longer than [1,2,3,4,5,..]" and B. "ie [0,1,2,3,4,..] is the same length as [1,2,3,4,5,..]" I think not. Obviously not. I know that this conclusion was qualified by "assuming that they all grow at the same rate", which of course has no counterpart in the denotational semantics setting discussed above. So it's not a wrong statement, just one that cannot really be formulated. Well, anyway, didn't want to be nitpicking. But I think it's important that if we want to think about Haskell's semantics denotationally (which in itself is somewhat problematic), we should at least be careful not to blur concepts. And asserting that the limit of a chain is always an element of that chain is a dangerous oversimplification that does not work out. Ciao, Janis Voigtlaender.

5 7

parsec, how to feed single tokens?
by Marc Weber 26 Jun '06

26 Jun '06

Hi. I want to write a haskellquickfind app to get a list of files using human readable hash values (eg the first character of directory/filenames) Eg hquickfind vtl should print /var/tmp/local My implementation should look like this: Every folder/file is token and I want to run a parser. to consume /var Then I want to run it with all subdirs in var where it should fail on anything but t.* ... My Problem : I can't access runP directly to feed the parser with one token and get the result (failure, need more tokens).. Have I missed a function or isn't parsec meant to be used this way? Would you recommend writing your own small parser for this? Another question: Can you use another SourcePos state than SourcePos? Marc

1 1