October 2006 - Haskell-Cafe

ghc 6.2.2 seems to ignore -package when there's a -prof option
by Seth Gordon 11 Oct '06

11 Oct '06

I have a program using HSQL that I'm trying to profile. When I do ghc program.hs -package hsql -o program it compiles fine, but when I do ghc -prof -auto-all program.hs -package hsql -o program I get error messages saying "failed to load interface for `Database.HSQL'" and so forth, the same way I do if I leave off the -package argument entirely. How can I work around this?

2 1

Trying to understand HList / hMapOut
by Matthias Fischmann 11 Oct '06

11 Oct '06

Hello, I am using a heterogenous list as in [1] all elements of which are of a given class C. I am awed by the beauty of the code (HList, not mine :-). Here is what I am trying doing: import HListPrelude data T = T Int class C a where foo :: a -> Int instance C T where foo (T i) = i class HList l => CList l instance CList HNil instance (C c, CList cs) => CList (HCons c cs) Since foo maps all class members to Int, hMapOut should be a straight-forward way to produce homogenous Int lists from heterogenous CLists: test :: (CList l) => l -> [Int] test = hMapOut foo That would be too easy, though... ghci (6.4) sez: /home/fis/tmp/Main.hs:16:7: Could not deduce (HMapOut (a -> Int) l Int) from the context (CList l) arising from use of `hMapOut' at /home/fis/tmp/Main.hs:16:7-13 Probable fix: add (HMapOut (a -> Int) l Int) to the type signature(s) for `test' or add an instance declaration for (HMapOut (a -> Int) l Int) In the definition of `test': test = hMapOut foo hugs (version 20050308) sez: ERROR "/home/fis/esim/HList/FakePrelude.hs":113 - Overlapping instances for class "Show" *** This instance : Show (HSucc a) *** Overlaps with : Show (HSucc HZero) *** Common instance : Show (HSucc HZero) (oops? should i upgrade, or is there a switch that i missed?) I am trying to understand the ghci error message, which looks like I might have missed a point. It seems like I should make it more obvious to ghc that CLists actually consist of values of type C. Is that a good guess? But how do I actually do it? I have unsuccessfully to extend the context to (HMapOut (a -> Int) l Int, CList l) or even to (C a, HMapOut (a -> Int) l Int, CList l) and I can't see any reason why the instance declarations of HMap in HListPrelude shouldn't cover my code. I am feeling a little stuck again... thanks, Matthias [1] http://homepages.cwi.nl/~ralf/HList/

3 7

windows file locking
by Stefan Aeschbacher 11 Oct '06

11 Oct '06

Hi I need to open a file and keep it open for writing (a log file). Another process has to read from this file. On windows the second process (e.g. tail -f) can not open the file. How can I open a file without this locking? regards Stefan

4 4

Vertical tabs in source code and other obscure chars
by Brian Hulley 11 Oct '06

11 Oct '06

Hi, In the Haskell98 report at http://haskell.org/onlinereport/lexemes.html section 2.2 has the rule: whitechar -> newline | vertab | space | tab | uniWhite Does anyone know what a vertical tab is supposed to do? Is there any reason to allow them as whitespace? (Does anyone in the universe actually use them?) Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

2 2

Re: Haskell-Cafe Digest, Vol 38, Issue 22
by Kirsten Chevalier 11 Oct '06

11 Oct '06

On 10/11/06, haskell-cafe-request(a)haskell.org <haskell-cafe-request(a)haskell.org> wrote: > Meanwhile, if you want to use External Core, but can't because it > doesn't work properly for you, don't be afraid to yell. (E.g. File a > Trac bug report.) I don't want to promise an immediate fix, but the > more people that use it the keener we are to get it done. > I did file a bug on this nine months ago: http://hackage.haskell.org/trac/ghc/ticket/670 but haven't had a chance to work on it. Cheers, Kirsten -- Kirsten Chevalier * chevalier(a)alum.wellesley.edu * Often in error, never in doubt "That's the thing about people who think they hate computers. What they really hate is lousy programmers."-- Larry Niven and Jerry Pournelle

1 0

GHC Core still supported?
by Jim Apple 11 Oct '06

11 Oct '06

In http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html , I see two notes that I can't verify: 1. I don't see any CORE pragma on http://www.haskell.org/ghc/dist/current/docs/users_guide/pragmas.html 2. Using GHC 6.5.20060920, I compile module Core where data Foo = Bar with -fext-core to get %module main:Core %data main:Core.Foo = {Bar}; I then compile the resulting hcr file with no flags to get <no location info>: 1: Parse error : %data main:Core.Foo = {Bar}; Jim

3 2

Multiple stages in Template Haskell
by Lyle Kopnicky 11 Oct '06

11 Oct '06

Hi folks, I noticed that in Template Haskell, you can only have one level of splicing or quasi-quoting. E.g., you can't write: $(zipN ($(sel 2 3) ("zip level",3,()))) ['a'..'Z'] [1..] (words "now is the time") Because you can't have a splice inside a splice. But wouldn't it be handy to use all these macros when defining other macros? This would be like stages in MetaML, which have no such limitation. But all the stages but the last one would be evaluated at compile time. The compiler would look for the deepest level of nested splices and evaluate it first. On the other hand, I can understand why you wouldn't include splices and quasi-quotes in the Language.Haskell.TH.Syntax - programmers could write functions that dynamically created arbitrarily (even infinitely) nested splices - so it would be undecidable where to start. I'm wondering if there's some reason this restriction is imposed. Is it particularly difficult to implement, or are there more theoretical problems? Does that mean I'm volunteering? ;) - Lyle

2 1

a monad for secret information
by Seth Gordon 11 Oct '06

11 Oct '06

I finally (think I) understand monads well enough to make one up: > module Secret (Secret, classify, declassify) > where > > data Secret a = Secret a > > classify :: a -> Secret a > classify x = Secret x > > declassify :: Secret a -> String -> Maybe a > declassify (Secret x) "xyzzy" = Just x > declassify (Secret x) _ = Nothing > > instance Monad Secret where > return = classify > (Secret x) >>= f = f x The nice thing about this is that (correct me if I'm wrong) clients of the module can't sneak information out of the monad without either using the right password or by using one of the unsafe*IO methods. (Or by running the program in a debugger. But you get the idea.) The not-so-nice thing is that the literal text of the password is baked into the data definition. I'd like to have a more general version of Secret that allows someone to pass the password in when constructing a secret, and preserves that password when "return" is used, but doesn't let the second argument of (>>=) see the password. Something like this:... > data Classification pw a = Classification pw a > declassify (Classification pw a) pw' = case pw' of > pw -> Just a > _ -> Nothing > > type Secret = Classification "xyzzy" ...but that doesn't parse. Is it even possible to have a type like this that still observes the monad rules? Is this the sort of thing that I need to understand arrows to pull off?

9 11

Haskell performance (again)!
by Yang 11 Oct '06

11 Oct '06

This email actually turned out much longer than I expected, but I hope it sparks interesting (and hopefully, thorough!) discussion on points that weren't touched on by previous threads on this topic. What follows describes my journey thus far exploring what I see (as a newcomer to Haskell) as a major problem with Haskell - the ease with which users can write inefficient code, and have no idea that they did. Some of this has to do with laziness, some of it with the functional programming in general. My goal is to achieve (as a link further down says) *good* performance, not blazing performance. I.e., I want to avoid what should really be no-brainers such as little-omega(1) space utilization for simple folds. The first version of a simple program I wrote was reasonably "clean." (Throughout this email, "clean" is supposed to mean some combination of: clear, compact, modular, elegant, etc.) It's a polynomial adder, which takes in lists of (coefficient, degree) tuples, combining terms of the same degree and maintaining a sorted order of least-to-greatest degree: type Poly = [(Int,Int)] addPoly1 :: Poly -> Poly -> Poly addPoly1 p1@(p1h@(p1c,p1d):p1t) p2@(p2h@(p2c,p2d):p2t) | p1d == p2d = (p1c + p2c, p1d) : addPoly1 p1t p2t | p1d < p2d = p1h : addPoly1 p1t p2 | p1d > p2d = p2h : addPoly1 p1 p2t addPoly1 p1 [] = p1 addPoly1 [] p2 = p2 addPoly1 [] [] = [] But this doesn't use tail recursion/accumulation (which seems to me like a complete hack that is a mandatory price to pay for using FP), so I rewrote it: addPoly :: Poly -> Poly -> Poly addPoly p1 p2 = let addPoly' p1@(p1h@(p1c,p1d):p1t) p2@(p2h@(p2c,p2d):p2t) result | p1d == p2d = addPoly' p1t p2t ((p1c + p2c, p1d):result) | p1d > p2d = addPoly' p1 p2t (p2h:result) | p1d < p2d = addPoly' p1t p2 (p1h:result) addPoly' (p1:p1s) [] result = addPoly' p1s [] (p1:result) addPoly' [] (p2:p2s) result = addPoly' [] p2s (p2:result) addPoly' [] [] result = reverse result in addPoly' p1 p2 [] But laziness will cause this to occupy Theta(n)-space of cons-ing thunks. (See appendix for a simpler example.) My third iteration will become even uglier because I will have to incorporate strictness and things like $! or seq. And there's probably a whole host of other issues that I haven't even thought of or don't know about (boxing, space leaks, etc.). >From #haskell, I got a general piece of advice: Oct 07 22:37:20 <Cale> Actually, a lot of the time, code gets messy when people optimise because they take the wrong road to optimisation Oct 07 22:37:31 <Cale> There are two ways to optimise a piece of Haskell code Oct 07 22:37:43 <Cale> You can make it stricter, forcing evaluation to occur sooner Oct 07 22:38:01 <Cale> Or you can make it lazier, ensuring that things are not demanded until actually needed Oct 07 22:38:09 <Korollary> @wiki performance Oct 07 22:38:09 <lambdabot> http://www.haskell.org/haskellwiki/performance Oct 07 22:38:13 <Cale> the latter route actually tends to result in cleaner code Of course, to want to learn route 2 was a no-brainer. I read through that wiki page on laziness and various other resources, but was disappointed in what I found: http://www.haskell.org/haskellwiki/Performance/Laziness only discusses the aspect of laziness where you only evaluate what you need, which by now has been repeatedly beaten into my head and sounds obvious. Aren't there other advantages to laziness? Or at least, am I not fully appreciating the "obvious" work-avoiding part of laziness? For instance, the example seems to allude to sharing (between the even and odd functions), which I think ties in strongly with laziness. I was hoping for more in-depth insights on how to take advantage of laziness to write cleaner AND more efficient code. (A loose analogy exists in computer architecture - the smaller the chip, the less power it can consume/the faster it can clock.) http://en.wikibooks.org/wiki/Haskell/Laziness_revisited does slightly better but still just scratches the surface - it gives an example of a clean (compact and modular) yet efficient piece of code (isSubstringOf), then completely neglects explaining it (e.g., exactly why/how does it run more efficiently?). http://users.aber.ac.uk/afc/stricthaskell.html seems to suggest that strictness is the way to go. Please say it ain't so! http://www.algorithm.com.au/mt/haskell/haskells_performance.html says that between code optimized for performance in Haskell and in another language (like O'Caml), "which is more declarative, high-level, and most importantly, which one doesn't require an expert in the language to write" is an unfortunate (for Haskell fans) no-brainer: "The problem then is you have to know why something is slow, and there's where Haskell can get complex. Is there a space leak? (Do you even know what a space leak is?) Is your array strict instead of lazy? If it's strict, is it boxed instead of unboxed? (Do you even know what unboxing is?) Can you use unsafeRead instead of readArray? (Did you know that unsafeRead exists? I sure didn't!)" So, how do I take advantage of laziness to write clean *and* performant code? I've been seeking resources with concrete examples, explanations, or guides on how to "systematically" do this. Is this even possible? Or am I deluding myself, and strictness is the way to go? If so, has there been any work/research to address the issues pointed out in the last blog entry? And do most (experienced) Haskell users sacrifice cleanliness for speed, or speed for cleanliness? I feel that an understanding of how Haskell compilers work would help immensely in writing more performant Haskell code (or just better Haskell code in general), as well as understand what optimizations are reasonable to expect from the compiler. (I have a university class of background on the design/implementation of simple lexers/parsers/compilers/interpreters/code block graph analyses for imperative OO languages. However, i'd love to learn more about these things for a language like Haskell, including details on lazy evaluation, pattern-matching, overloading (why it's slow), currying, PFA, type classes, monads, etc. Preferrably something "lighter weight" than a bunch of research papers. Any pointers?) BTW, please also feel free to give me feedback/refinements on my code snippets. :) Thanks a ton for any enlightenment! Yang Aside: http://www.matthewmorgan.net/blog/archives/2004/10/07/haskell-performance. This post brings up a most reasonable point (venturing off onto tangent now) - space leaks are a much more serious concern than performance, and they're a difficult problem even for experienced Haskell users (http://www.haskell.org/pipermail/haskell-cafe/2003-December/005587.html)

13 19

Profiling CAFs (re-post)
by Matthias Fischmann 11 Oct '06

11 Oct '06

Hi again, I posted a bunch of questions on profiling here a few days back, but couldn't tickle anybody to post a reply. Since I am not tired any more today, but still can't understand the documentation, or the output of the profiler, here it goes again: What qualifies as constant applicable form, and why is it not labelled in a more informative way? Why are there functions that inherit all of their (considerable) time and space consumption from elsewhere, but nothing in the list would allow for such a rich inheritage? As I said, I am happy to set up a wiki page if I learn anything that helps me improve the utility of profiling (the profiler and the rudimentary documentation are of great value as is). And i am happy to take pointers and go read articles if you tell me they help in the everyday work with ghc profiling. thanks / cheers, matthias

3 4