- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] extreme newbie: hugs prompt vs load module
by Hans van Thiel 24 Aug '06

24 Aug '06

Hi, I'm a beginner too and I'm quite taken with 'Yet Another Haskell Tutorial' by Hal Daume III, which is available from the Haskell site. It really starts from scratch and it covers almost everything, as far as I can see. Because I'm a lone learner, I got stuck several times, but there are several other short tutorials for beginners, with a slightly different slant, that helped. For monads, which I'm starting on now, I recommend 'All about Monads' by (Jeff?) Newbern. http://www.nomaware.com/monads/html/ But YAHT starts with a chapter on Hugs, GHC and how to use them. At the moment I'm reading the book again, from the beginning, and I'm seeing several things much better than I did the first time(s). Hope this helps, Hans van Thiel -- Don't worry, be happy, learn Haskell.

1 0

Memoizing longest-common-subsequence
by Mark.Carroll＠Aetion.com 23 Aug '06

23 Aug '06

I wanted a longest common subsequence function and a bit of Googling failed to turn up a functional one, except for in a scary bit of darcs. So, I tried making a memoized functional version of the LCS delta algorithm on the problem's Wikipedia page. It's not the fastest, but it's simple and should be polynomial, growing with the product of input sequence lengths. I've not played with unboxing or strictness here yet, but with the help of Data.Array I have: longestCommonSubsequence xs ys = let lastIndex = (length xs, length ys) memo = array ((0, 0), lastIndex) [ ((xi, yi), deltaLCS (xi, x) (yi, y)) | (xi, x) <- zip [0..] (undefined : xs), (yi, y) <- zip [0..] (undefined : ys) ] deltaLCS (0, _) _ = (0, []) deltaLCS _ (0, _) = (0, []) deltaLCS (xl, x) (yl, y) = if (x == y) then let (xylShrunk, xysShrunk) = memo ! (xl-1, yl-1) in (xylShrunk + 1, x : xysShrunk) else let xaShrunk@(xlShrunk, _) = memo ! (xl-1, yl) yaShrunk@(ylShrunk, _) = memo ! (xl, yl-1) in if xlShrunk > ylShrunk then xaShrunk else yaShrunk in reverse (snd (memo ! lastIndex)) I haven't looked much at optimizing this further so there are probably yet some easy wins to be had - I'd be interested to see what they are. Still, I thought it worth sharing as an example of laziness making memoization easy in a simple functional longest common subsequence example. Take this as your cue to point out the much better LCS algorithm that already exists in the standard libraries, that I couldn't find. (-: -- Mark

6 10

debugging space leaks in references
by Andrew Pimlott 23 Aug '06

23 Aug '06

GHC's great space profiling tools don't appear to be much help when your leaked memory is stored in references (IORefs, StablePtrs, etc). I had a real-life case where the allocation profile showed me where the leaked data came from, and I could guess that it was being held by some reference, but I couldn't tell which one. Retainer set profiling showed a big suspicious entry for "SYSTEM", but I couldn't find any way to pinpoint the problem. (It ended up being a missing freeStablePtr in hsgnutls, found by code inspection.) Here's a contrived example that just allocates a bunch of IORefs: import Control.Monad import Data.IORef main = repeatM (newIORef [1,2,3]) repeatM io = liftM2 (:) io (repeatM io) Retainer set profiling shows everything in "SYSTEM". None of the other profiling methods say anything interesting either. What I'd like to get, I think, is (1) your memory is being held in IORefs (2) allocated by this cost center and (3) being retained by this cost center. I guess I'm looking for something like a memory profiler for a traditional language. But I haven't really thought it all out (and I don't even understand everything the existing profiles tell me). Are there some tricks I've missed for this sort of debugging? And perchance would this be an interesting GHC hackathon subject? Andrew

1 0

Haskell wiki: most popular pages
by Bulat Ziganshin 23 Aug '06

23 Aug '06

Hello haskell-cafe, The http://haskell.org/haskellwiki/Special:Popularpages page lists most popular pages on haskell wiki. I think this list is very useful because it shows us what are the questions about Haskell people most interested and gives us hints what should be improved in first place. The only catch is that most of popular pages are just ones listed on the title page. But nevertheless... On the other side, we can simplify title page by omitting links to page that are of little interest for casual readers (such as History). We can also add here links to most popular pages, such as GHC and "Hitchhikers guide". Below is beginning of this list: Haskell (252,505 views) Introduction (50,091 views) Libraries and tools (41,864 views) Books and tutorials (40,040 views) Language and library specification (32,773 views) Haskell in practice (31,698 views) Implementations (24,141 views) GHC (20,634 views) Haskell in 5 steps (16,707 views) Learning (14,088 views) Hitchhikers guide to Haskell (13,191 views) Future (12,754 views) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

6 13

DiffArray is an unsaturated type?
by Neil Mitchell 23 Aug '06

23 Aug '06

Hi, I note that in the base libraries, Data.Array.Diff is defined as: type DiffArray = IOToDiffArray IOArray However, IOToDiffArray takes 3 parameters. I thought this was not allowed in Haskell 98? Its annoying from my point of view because Hoogle wants to know the arity of a type, and if it has to chase down the arity of the RHS to do it, I probably just won't bother. Is there any difference between the above definition and: type DiffArray a b = IOToDiffArray IOArray a b Is the first prefered for any reason? Thanks Neil

2 1

Useful: putCharLn {inspire by the Int->[Char] thread
by Gene A 23 Aug '06

23 Aug '06

The thread on the use of "show" and print to display an Int value, brought up a problem I had early on... the one of cleanly displaying a Char value, on a line all by itself.. My first attempts: This was just plain hard to read: with the character t being where it was: Prelude> putChar $ head "this and that" tPrelude> ----------------------- So I tried this and of course ... type mismatch: Prelude> putStrLn $ head "this and that" <interactive>:1:16: Couldn't match `String' against `Char' Expected type: [String] Inferred type: [Char] In the first argument of `head', namely `"this and that"' In the second argument of `($)', namely `head "this and that"' ---------------------- So I did this... to manually turn it to a string and it does work, but a little cumbersome to work into other function calls: Prelude> putStrLn $ (head "this and that"):[] t ------------- so the definition of putCharLn came to life {may be in some library already and I just haven't found it yet.. but it is in my toolbox now}: Prelude> let putCharLn c = putStrLn (c:[]) Prelude> and an application of it: Prelude> putCharLn $ head "this and that" t --------------- now I also have the char to string conversion alone: c2Str c = c:[] Prelude> let c2Str c = c:[] Prelude> c2Str 'A' "A" ------------------ Now this is almost too trivial a thing to mention these gizmos... what with all the monadic constructions that greater minds toss about on this list.. and I am trying to get understanding of that still, but .... sometimes we just accept the unacceptable little irritants rather than just code a solution, no matter how simple it is. There are probably troves of simple workarounds out there that seem too trivial to mention but hey, share 'em... might hit a guy like me that says. "now why didn't I think to do that?" happy days, gene

7 9

Writing binary files
by Neil Mitchell 22 Aug '06

22 Aug '06

Hi, I'm trying to write out a binary file, in particular I want the following functions: hPutInt :: Handle -> Int -> IO () hGetInt :: Handle -> IO Int For the purposes of these functions, Int = 32 bits, and its got to roundtrip - Put then Get must be the same. How would I do this? I see Ptr, Storable and other things, but nothing which seems directly useable for me. Thanks Neil

5 5

Fw: [Haskell-cafe] A restricted subset of CPP included in a revisionof Haskell 98
by Brian Hulley 22 Aug '06

22 Aug '06

Hi - here is an exchange that was off-list by accident: ---- Original Message ---- From: Brian Smith To: Brian Hulley Sent: Tuesday, August 22, 2006 5:50 AM > (Brian, I see that my last reply only went to you and so I forwarded > it to the list. Since you replied to me directly, I am responding to > you directly. Feel free to forward this to the list if you want). > > > On 8/21/06, Brian Hulley <brianh(a)metamilk.com> wrote: >> The paper "Template meta-programming for Haskell" suggests >> that Template Haskell should be able to do everything that CPP >> is used for at the moment, such as conditional compilation, macros >> etc, so this might be a possible option, though I have to admit apart >> from reading the paper and doing a few experiments with it I don't >> know enough about the current state of TH to know if it would be a >> viable replacement at the moment. > > I am very interested in TH and I hope to give it a thorough workout > on an upcoming project. Until then, I don't know enough about it to > compare it to CPP. But, I think that in an Editor/IDE, a restricted > CPP would be much easier to implement than TH. > > >> I've got a feeling that even allowing #define could break the >> invariant that a module only has one meaning in a program, since >> #define changes the state of a symbol that's not yet been mentioned >> just as #undef changes the state of a defined symbol eg: >> >> >> module P where >> #define Bar >> import R >> >> module R where >> #ifdef Bar >> import S >> #else >> import T >> #endif >> >> module Q where >> import R > > I think that this program will only compile if it is split into three > files, P.hs, R.hs, and Q.hs. There would be two scopes for CPP > macros: global (each macro is bound to exactly one value for all > modules, and it cannot be undefined or redefined) and file/module > (the macro is bound exactly once in a module and that binding is not > visible to other modules). Except for the "exactly once" part, this > is how GHC and cpphs already work. > > So, in your example, let's assume there is no global binding for > "Bar"--if there was, then there would be a redefinition error in > P.hs. Then, P.hs defines Bar, but this binding is in scope only > inside of P.hs--R.hs does not "see" Bar as being defined. Further, > since R.hs does not contain a binding for "Bar," so module R will > always import module T and never module S. > > A more concrete example is this: > > module P where > #ifdef __GHC__ > import P.GHC > #else > import P.Haskell98 > #endif > > In your editor/IDE you might want to support multiple Haskell > implementations. So, sometimes __GHC__ will be defined (when in GHC > "mode") and sometimes it won't. But, I recommend to handle this in > the same way that IntelliJ handles the JDK setting. That is, if the > user wants to switch the implementation he is using (even > temporarily), then when he does so, the whole program gets > reanalyzed. If the user wants to work in Hugs mode and GHC mode in > the same time, then he should create two projects in the IDE. In one > project, the implementation will be set to GHC, and the other one > Hugs. He will have to define output paths, etc. such that the two > project's ouitput files do not overlap even though their sources > will. Then, analyze each project seperately. This technique also > allows the user to build a version of the project against, say, HaXml > 1.14, and other version against 1.15. > > >> Much as I'd like to not have to deal with CPP, I agree that on >> a practical realistic level it's not going to go away immediately, >> but at least the guidelines you posted give a good starting point >> for library authors to gradually try and reduce the dependence >> on the preprocessor, if they are motivated to (which they >> probably aren't ;-) ) > > Right. Plus, if we follow the guidelines I proposed very strictly, > then we can more easily picture what is required of a CPP > replacement. For example, if the guidelines are too prohibitive, then > we will know we need something more powerful like TH. If the > guidelines do not result in any practical loss of functionality, then > we know that we can get by with a much simpler configuaration > language. > > >> I had a wild idea of a tool to eliminate CPP from a source >> tree by first generating the set of N pre-processed source trees >> (ie now pure Haskell) then running some analysis tool over these >> trees to automatically factor out common code, but this would >> probably be a major undertaking. > > That would definitely be an interesting project, and it would be > useful for other things as well (The duplicate code detection part.) > > > >> Cabal seems to help a lot - Edison and ByteString both built on >> my machine with no trouble at all. I think the more everything can >> be done in Haskell the better it will be. > > I agree. But, I also want it to be easy to reuse C-based libraries > whenever possible. That way, we can spend more time writing code in > Haskell that does new things instead of reimplementing old ideas in > it. > > > You mentioned that library maintainers might not be motivated to make > such changes. I think that people will modify their libraries if > there are compelling tools that need those modifications. In fact, I > think people would even be willing to break previous commitments to > backwards compatibility if there was any benefit to doing so--I mean, > who really uses the latest version of HaXml with GHC 5.x or Hugs > 2002-xx-xx? > > If there was an IntelliJ-level IDE for Haskell, and people were > writing "real world" programs in Haskell, then somebody would get > around to modifying libraries to work for "real world" programs built > using such a tool. Or, somebody that had a commercial interest (a > Haskell consultant or an IDE vender) might make these modifications. > > - Brian

1 0

Description of Haskell extensions used by FPTOOLS
by Brian Smith 22 Aug '06

22 Aug '06

Is there any design document for the FPTOOLS libraries or some description of language features that are (allowed to be) used in them? I am going to be taking some significant time off from my normal jobs in the upcoming months. During part of that time, I would like to do some work to improve the Haskell toolchain. This involves creating or improving tools that parse and analyze Haskell code. My goal is to have these tools support enough of Haskell to be able to handle at least the most important libraries used by Haskell programmers. In particular, this includes all or most of the libraries in FPTOOLS. Plus, I want these tools to operate on Darcs as it is an obvious poster-child for Haskell. Thus, I need to support Haskell 98 plus all the extensions being used in Darcs and FPTOOLS as of approx. March, 2007 (as I intened to start working again at that time). It would be very nice if there was some document that described "Haskell 98 plus all the extensions being used in Darcs and FPTOOLS as of March, 2007." Besides being useful to me, it would be a useful guide for potential contributors to FPTOOLS. Regards, Brian

6 6

Fwd: [Haskell-cafe] A restricted subset of CPP included in a revisionof Haskell 98
by Brian Smith 22 Aug '06

22 Aug '06

On 8/20/06, Brian Hulley <brianh(a)metamilk.com> wrote: > Henning Thielemann wrote: > > On Thu, 17 Aug 2006, Brian Smith wrote: > > > >> I find it strange that right now almost every Haskell program > >> directly or indirectly (through FPTOOLS) depends on CPP, yet there > >> is no effort to replace CPP with something better or standardize its > >> usage in Haskell. > > > > I think there should be more effort to avoid CPP completely. > > I agree, especially as I'm trying to write an editor for Haskell which > will > certainly not cope with CPP at all! ;-) I agree with this sentiment. But, CPP also has some advantages over the other suggestions presented here. Using CPP, we can create libraries that work with GHC 5.x and old versions of Hugs. If an alternative to CPP were chosen, would we update fptools to use this alternative? If it involves new syntax, then updating FPTOOLS to use the new syntax would break backward compatibility. And, if (the vast majority of) FPTOOLS does not use the solution then it is not useful. The reason it would not cope is that CPP turns what would otherwise be one > program/module/library into several programs/modules/libraries which > simultaneously co-exist in the same text in a rather uneasy and vague > relationship, and what's even worse: the same module can have multiple > meanings in the *same* program depending on use of #ifdef #undef etc, thus > making code navigation quite impossible: the meaning of each module now > depends on how you got there and might even be different the second time > round... Notice that with my suggestions none of these problems apply, because all external "command line" parameters have a single static value over the whole program (two modules cannot depend on differing values of a single macro, #undef is not allowed). Changing the bindings for these macros would invalidate any cached information the editor has. But, the editor has to support updating its caches anyway, to deal with switching libraries in/out, etc. I won't use an IDE effectively if it can't handle the libraries in FPTOOLS, which liberally use the preprocessor. Either the IDE has to handle the preprocessor or the libraries have to stop using them, or they have to meet somewhere in the middle. I think the acid test would be to reach a point where anyone can download > the source for some large program such as GHC and just type ghc --make > Main > and expect the program to be built in one pass with no problems. I agree with this sentiment as well. Most of the little data processing programs I have written are built exactly like that already. How can we get the existing libraries to build like that though? - Brian

1 0