August 2009 - Haskell-Cafe

Uncontrolled Concurrency, isn't that concept now thread-bare?
by Casey Hawthorne 17 Aug '09

17 Aug '09

-- Regards, Casey

1 0

DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
by Peter Verswyvelen 17 Aug '09

17 Aug '09

I knew about DDC for a while but never bothered to look at it deeply since it was so young, and at first sight it just did what ML did (silently allowing side effects). But when looking again at it, it seems it actually does some very clever things to allow side effects and still be safe, a bit what one does explicitly with Haskell's ST and IO monads, but in DDC, the compiler seems to analyze where side effects happen and automatically annotates/enrich the types (with things like region, closure and effect information) to indicate this. The example given by DDC is that in Haskell, you need two versions of each higher order function if you really want your library to be reuseable, e.g. you need map and mapM, but in DDC you just need one function, map, which also is written in a pure style. See e.g. http://www.haskell.org/haskellwiki/DDC/EffectSystem I kind of agree with the DDC authors here; in Haskell as soon as a function has a side effect, and you want to pass that function to a pure higher order function, you're stuck, you need to pick the monadic version of the higher order function, if it exists. So Haskell doesn't really solve the modularity problem, you need two versions of each higher order function really, and you need to carefully plan ahead of time if you want to write in a monadic or pure style, and it also splits my brain mentally ("side effects are ***evil***. But hang on, how can I e.g. do a depth first search efficiently purely functional? Damn, it seems I can't! Let's switch back to C#/C++!!! Nooooo ;-) This seems to make Haskell not a good language for doing things like extreme programming where code evolves, unless you have some insanely clever refactoring tool ready that can convert pure into monadic functions and vice versa. Is it true that - as in DDC - side effects can be analyzed by the compiler (in the same sense that say, strictness is analyzed), freeing the library and user from writing/picking monadic versions??? If so, would this indeed solve the modularity/reusablity issue? I feel you can't have your cake and eat it here, so there must be catch? :-) Thanks for sharing any thoughts on this, Peter Verswyvelen

28 72

Blank definition list in haddock
by Maurício CA 16 Aug '09

16 Aug '09

I read in haddock documentation that we write definition lists like this: -- [@something@] Definition of something. However, using that structure to document many itens, I get a blank list of definitions, like you can see in this section ('Macros') of the documentation for a package of mine: http://hackage.haskell.org/packages/archive/bindings-common/0.2.2/doc/html/… However, as can be seen in the source code, there are many definitions inside 'Macros' section. http://hackage.haskell.org/packages/archive/bindings-common/0.2.2/doc/html/… Did I used those definitons the wrong way? Thanks, Maurício

2 2

ANN: Haddock version 2.5.0
by David Waern 16 Aug '09

16 Aug '09

-------------------------------------------- -- Haddock 2.5.0 -------------------------------------------- A new version of Haddock, the Haskell documentation tool, is out! If you're using GHC 6.10.2 and Haddock 2.4.2, you should be able to upgrade to this version without any problem. If you're using something else, you should re-install any documentation that you want to link to after upgrading. Please use the bug tracker to submit bug reports or feature requests. -------------------------------------------- -- Changes in version 2.5.0 -------------------------------------------- * Drop support for GHC 6.8.* * Add support for GHC 6.10.3 and 6.10.4 * Revert to the old multi-page index for large packages (#106) * Show GADT records in the generated documentation * Create the output directory if it doesn't exist (#104) * Use the native codegen instead of compiling via C for TH modules * Add --use-unicode flag for displaying prettier versions of common symbols * Mutiple verbosity levels: remove --verbose and add --verbosity=n * Simpler versioning of .haddock files To avoid slow search, Haddock switches from the searchable index to the old multi-page index for large packages (containing over 150 items). This, and support for GADT records in the generated documentation was implemented by Isaac Dupree as part of his Summer of Code project. The --use-unicode flag was contributed by George Porges. -------------------------------------------- -- Links -------------------------------------------- Homepage: http://www.haskell.org/haddock Hackage page: http://hackage.haskell.org/package/haddock-2.5.0 Bugtracker and wiki: http://trac.haskell.org/haddock Mailing list: haddock(a)projects.haskell.org Code repository: http://code.haskell.org/haddock -------------------------------------------- -- Contributors -------------------------------------------- The following people contributed patches to this release: Isaac Dupree Ian Lynagh Simon Marlow Simon Peyton-Jones George Porges David Waern -------------------------------------------- -- Future Plans -------------------------------------------- Here are the top priority tickets right now: * Cross-package documentation (#24) * Good warning messages when encountering unexpected Haddock comments (#94) * Comments on instance declarations (#29) Isaac Dupree has been working on the first item as part of his SoC project and it is near completion. If you have any input on what we should prioritize, add yourself to the CC list of the ticket(s) that you are interested in. -------------------------------------------- -- Get Involved -------------------------------------------- We would be very happy to get more contributors. To get involved, start by grabbing the code: http://code.haskell.org/haddock Then take a look at the bug and feature tracker for things to work on: http://trac.haskell.org/haddock

3 4

qsort
by Peter Verswyvelen 16 Aug '09

16 Aug '09

I was reading the introduction at http://www.haskell.org/haskellwiki/Introduction where the typical Haskell version of qsort is given qsort [] = [] qsort (x:xs) = qsort (filter<http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:filter> (< x) xs) ++<http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:.> [x] ++<http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:.>qsort (filter<http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:filter> (>=<http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:>=>x ) xs which is then compared to the inplace C version, showing off how much shorter the Haskell version is. However, the page also has a link to a "semi-direct" translation of the C version, which then brings the user to all kinds of confusing threads and texts, like *"**Unfortunately none of the above "real" quicksorts seems to compile as given, when copy/pasted into ghci. Can someone fix? The "parallel" quicksort gave error "unknown package concurrent" when I ran make in quicksort/gransim. Has anyone got a functioning "real" quicksort that works on copy/paste? The program below is working very very slowly. It's probably slowsort... :o)"* * * Furthermore the inplace versions of qsort in Haskell are IMO less readable than the C version. I'm not sure but if I would be a beginner I might get confused by this. It is often claimed that compiler technology will make it possible to compile high level code into efficient low level code that is almost as efficient as the C or asm routines. How does this apply to qsort today? Cheers, Peter Verswyvelen

3 2

GSoC profiling project to be wrapped up
by Patai Gergely 16 Aug '09

16 Aug '09

Hi everyone, I finally uploaded the profiling tools to Hackage. The package names are hp2any-{core,graph,manager}. The first two should be possible to install right away, while the manager needs Gtk2Hs. A bit more on the project and this update at <http://just-bottom.blogspot.com>. Gergely -- http://www.fastmail.fm - IMAP accessible web-mail

3 4

why does the binary library require so much memory?
by Jeremy Shaw 16 Aug '09

16 Aug '09

Hello, Using encode/decode from Binary seems to permamently increase my memory consumption by 60x fold. I am wonder if I am doing something wrong, or if this is an issue with Binary. If I run the following program, it uses sensible amounts of memory (1MB) (note that the bin and list' thunks won't actully be evaluated): import Data.Binary main :: IO () main = let list = [1..1000000] :: [Int] bin = encode list list' = decode bin :: [Int] in putStrLn (show . length $ takeWhile (< 10000000) list) >> getLine >> return () /tmp $ ghc --make -O2 Bin.hs -o bin /tmp $ ./bin +RTS -s /tmp/bin +RTS -s 1000000 68,308,156 bytes allocated in the heap 6,700 bytes copied during GC 18,032 bytes maximum residency (1 sample(s)) 22,476 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 130 collections, 0 parallel, 0.00s, 0.00s elapsed Generation 1: 1 collections, 0 parallel, 0.00s, 0.00s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.05s ( 0.92s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.05s ( 0.92s elapsed) %GC time 0.0% (0.1% elapsed) Alloc rate 1,313,542,603 bytes per MUT second Productivity 100.0% of total user, 5.7% of total elapsed According to top: VIRT RSS SHR 3880 1548 804 Now, if I change *list* in the last line to *list'* so that the encode/decode stuff actually happens: /tmp $ ./bin +RTS -s /tmp/bin +RTS -s 1000000 617,573,932 bytes allocated in the heap 262,281,412 bytes copied during GC 20,035,672 bytes maximum residency (10 sample(s)) 2,187,296 bytes maximum slop 63 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 1151 collections, 0 parallel, 0.47s, 0.48s elapsed Generation 1: 10 collections, 0 parallel, 0.36s, 0.40s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 0.47s ( 20.32s elapsed) GC time 0.84s ( 0.88s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.30s ( 21.19s elapsed) %GC time 64.1% (4.1% elapsed) Alloc rate 1,319,520,653 bytes per MUT second Productivity 35.9% of total user, 2.2% of total elapsed And top reports: VIRT RSS SHR 67368 64m 896 63 times as much total memory in use. And, this is while the program is waiting around at 'getLine' after it is 'done' with the data. I am using GHC 6.10.4 on GNU/Linux. Thanks! - jeremy

6 14

Re: [Haskell-cafe] Elerea/GLFW Tetris
by Patai Gergely 15 Aug '09

15 Aug '09

> Here is my first real program in Haskell. How come you started out with playing around with FRP libraries right away? It's a rather peculiar choice, I'd say. > In fact, I'm not fully responsible because it's just an adapted > version of a Tetris Creighton Hogg had written for Reactive/GLUT. > As the first version, it's a very simple game (no levels, no > points ...) but it's playable ! It's an interesting exercise, and quite a nice job from someone who considers themselves a beginner. One thing I don't really understand is why you packed up those applicative combinators in a SignalMonad, i.e. the reason behind flat and sf_sa. You have much more freedom in using them as they are, since they can appear inside any expression. For instance, you could just say the following in the let declaration: sfall = (uncurry . fall) <$> randomBehavior seed sid = pure id Or even better, since both sfall and sid are created by pure combinators, you don't even need to name them if they are used only once anyway: autumn = ifte metronome ((uncurry . fall) <$> randomBehavior seed) (pure id) Another thing, which is really a matter of taste, is that you seem to like point-free style acrobatics. I don't think it's always the best choice, especially if you are to share code with others, since most people grok code with explicit parameters easier than magic involving flip and const and (un)curry and the like, except for the obvious cases of composing a chain of operations, where dropping arguments feels quite natural. For instance, the definition of f_a looks problematic to me because of these concerns. Gergely -- http://www.fastmail.fm - Same, same, but different...

2 1

Re: [Haskell-cafe] Improving event management in elerea
by Patai Gergely 14 Aug '09

14 Aug '09

> can you explain, please ? I can't feel it when I play. Well, the paddle moves very fast that way, and its speed depends on the refresh rate. While the refresh rate is set in this program, it's not a good idea to depend on it in any way. Transfer functions provide access to the frame time, so you can adjust the speed to be independent of it. > or using some rounding as I did in my first implementation ? It's good if that works. However, I wouldn't depend on that either, since you might have to struggle with edge cases, and you also rely on the sizes being related to each other in various ways instead of choosing them freely. In my opinion, the best solution in this case would be a clamped integral, which would also make it unnecessary to check for the edge of the field in the condition (note that I make use of the Num instances of signals to take care of the lifting): integralClamped v0 vmin vmax s = transfer v0 accum s where accum dt v v0 = max vmin $ min vmax $ v0+v*realToFrac dt playerX <- integralClamped playerX0 (-fieldW) (fieldW-playerW) (ifte lpress (-1) 0 + ifte rpress 1 0) >From these, integralClamped and ifte might also be good candidates for inclusion in the library. Gergely -- http://www.fastmail.fm - Choose from over 50 domains or use your own

2 1

Re: Adding an ignore function to Control.Monad
by Jeff Wheeler 14 Aug '09

14 Aug '09

On Fri, Jul 10, 2009 at 10:10 PM, Don Stewart<dons(a)galois.com> wrote: >> ## Control.Monad.void m a -> m () >> Don Stewart >> Iavor Diatchki For whatever it's worth, I prefer void as well, for the exact reason Don said. Indeed, 'ignore' indicates to me that the argument won't even be evaluated: it'll be ignored, and skipped. But it is, and only part --- the result --- is ignored. What about 'void' with functors? Jeff Wheeler

8 7