- Haskell-Cafe - Haskell.org

Another idea for record field selection and better namespace management
by Brian Hulley 27 Jan '06

27 Jan '06

Hi - To avoid the problems with so many names being put into a module's namespace, data declarations could implicitly define sub-modules and class/instance declarations as follows: module M where data Foo = FooCon {x : Int} would declare (as seen from inside M) Foo, Foo.FooCon, Foo.x and would further declare x and FooCon as instances of a global value type-class and constructor type class as follows (where //varid denotes the global typeclass corresponding to (a record field called) varid, and //conid denotes the global typeclass corresponding to the constructor conid) class //x a b where x : a -> b instance //x Foo Int where x Foo.FooCon{x=p} = p class //FooCon a b where FooCon : a -> b instance //FooCon Int Foo where FooCon = Foo.FooCon The class declarations (generated by the compiler) are global, and there is no danger of conflicts with user class declarations because of the // prefix. The instance declarations (also generated by the compiler) would be inserted into the module itself. This would give at least three advantages: 1) The same names could be used for fields in more than one data declaration and these would be resolved using the well known type class mechanism 2) Some exciting new programming paradigms become instantly available due to the extension of allowing constructor type classes, namely we could then get the effect of extensible data types eg data Col1 a = One a data Col2 a = One a | Two a useOne :: ( //One col a) => col -> a useOne (One x) = x This is a lot more powerful than just OOP, because we could have different views of a data type, selecting out those components which are relevant to particular operations: data Element = TerminalPunct | TerminalValue | NonTerminal | Push | Pop data Action = Push | Pop data Insertion = TerminalValue | NonTerminal | Push without having to artificially construct various injections... 3) If x is a record field, then because a typeclass and instance has been automatically generated, (x p) already uses the type of p to determine which overloaded x to use, so all that remains is to introduce a sugar to get a form of function application syntax that binds stronger than prefix application. I suggest p^x === (x p) It is still possible to be completely explicit, by writing P.x p or p^P.x I think this solves all the problems that I had with the value space idea, and is also a fairly conservative extension to Haskell as it stands at the moment, except I wonder if it is possible to implement type classes for constructors? Regards, Brian.

1 2

graphics Windows Programming
by Andrew U. Frank 26 Jan '06

26 Jan '06

There are several graphics packages to select from... But which one is the easiest to work with for students for a ghci - windows environment. I sense that cairo / gtk2hs does not support ghci. >From the HOpenGL home page I cannot find out what I would need to download for a windows environment (can somebody point me to the right direction?). We have used SOE under hugs but I sense it is not working with ghci? We found it also somewhat deficient for graphics beyond the content of the book - has it been extended and improved? Any advice greatly appreciated! Andrew Frank

2 1

HitchhickersGuideToTheHaskell - Chapter 3 ...
by Dmitry Astapov 25 Jan '06

25 Jan '06

... which deals with QuickCheck and type classes, have been uploaded to http://www.haskell.org/hawiki/HitchhickersGuideToTheHaskell. Any feedback and criticism is gratly appreciated! -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D

1 0

Printing functions
by Creighton Hogg 25 Jan '06

25 Jan '06

Hi, I'm working on writing a genetic programming system in Haskell, and I wanted to know what might be a good way to print out the programs that are being generated. There's no instance of Show for functions, but I'd really like to see what's happening so that I know if it's working right. What should I try?

2 1

Hashtable woes
by Chris Kuklewicz 25 Jan '06

25 Jan '06

Hello, This post is a about a tangential issue to the shootout, not the shootout itself. It concerns the lack of a fast mutable hashtable. If you have a good replacement for Data.Hashtable, I would be interested to know about it (and so would the wiki!). The shootout entry "k-nucleotide" is a good test of the hashtable provided by each of the languages: http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lang=a… Several of us are building a proposed entry on the wiki at http://haskell.org/hawiki/KnucleotideEntry where I have just posted a plea which I will paste below: On mutable data structures in Haskell This benchmark is completely bottlenecked by Data.Hashtable (in GHC 6.4.1) and this discussion is based on the assumption that I am using Hashtable optimally. I downloaded the GHD 0.17 compiler and the DMD entry to benchmark on my machine. The DMD entry uses the "associative arrays" built into the language: "int[char[]] frequencies" and places [WWW]second (runs in 3.0s). The winning entry is interesting, since the c-code does not have a hash table, and so it uses #include "../../Include/simple_hash.h" which pulls in a dead simple, inline, string to int hashtable and runs in 2s. The entry below runs 16 slower than the DMD entry on my powerbook G4. Profiling shows the bottleneck. I downloaded simple_hash.h and shamelessly optimized it to replace Data.Hashtable for exactly this benchmark code. This sped up the proposed entry by a factor of 4.1 so that it is now about a factor of 4 slower than the DMD entry. This shows that Data.Hashtable is doing *at least* four times more work that is needed for this usage pattern. And even with my over specialized hash table, Haskell is almost 50% slower than OCaml's "module H = Hashtbl.Make(S)" (note that I my code uses the same hash function as OCaml). Unfortunately I cannot submit this optimized hash table entry to the shootout. The only mutable data structure that come with GHC besides arrays is Data.Hashtable, which is not comptetitive with OCaml Hashtbl or DMD's associative arrays (unless there is something great hidden under Data.Graph). Is there any hope for GHC 6.6? Does anyone have pointers to an existing library at all? Perl and Python and Lua also have excellent built in hashtable capabilities. Where is a good library for Haskell? -- Chris Kuklewicz

5 6

compiling lazy functional languages
by Sam Goldman 25 Jan '06

25 Jan '06

Sorry if this is too off-topic for this list. I'm a hobbyist programmer and I've recently become interested in lazy functional languages, particularly the optimization strategies available to them during compilation. I've been playing around with Haskell for about a year and it has been an excellent resource for me. I guess my main question is this: what are the x most compelling directions in optimized compilation for (pure) lazy functional languages in recent research (where x::Nat is an unevaluated thunk in your head) - Sam

4 3

darcs: the first haskell tool more popular than Haskell itself?
by Isaac Jones 25 Jan '06

25 Jan '06

Greetings, Debian has a system called popularity-contest, which is an opt-in survey of package use. I was curious to see the ranking of darcs among Haskell implementations themselves. The results: Darcs ranks higher than ghc and hugs. #<name> is the package name; #<inst> is the number of people who installed this package; #<vote> is the number of people who use this package regularly; #<old> is the number of people who installed, but don't use this package # regularly; #<recent> is the number of people who upgraded this package recently; #<no-files> is the number of people whose entry didn't contain enough # information (atime and ctime were 0). #rank name inst vote old recent no-files (maintainer) 138 darcs 563 159 280 124 0 (Isaac Jones) (51) hugs 304 119 157 28 0 (Isaac Jones) 321 ghc6 194 81 80 33 0 (Ian Lynagh) Hugs is listed in a different category, so the ranking is off. Ian Lynagh pointed me at this nice graph showing the historical installation of the three packages: http://people.debian.org/~igloo/popcon-graphs/index.php?packages=ghc6,darcs… peace, isaac

5 6

Guess what ... Tutorial uploaded! :)
by Dmitry Astapov 24 Jan '06

24 Jan '06

Hi all, Recend thread "Tutorial upload" reminded me of my intentions to write haskell tutorial which I suppresend from the times when Hal Daume began to write YAHT. Unusually low temperature here (-22C) freed me a lot of time this weekend, and the result it here: http://www.haskell.org/hawiki/HitchhickersGuideToTheHaskell This is a work in progress, plus I'm trying it on C++/Java folk around me, so it's bound to be heavily corrected, but main direction could already be seen (I hope). If you want - jump on the wagon, and provide me with (constructive) criticism, edits on hawiki or anything else you see fit. -- Dmitry Astapov //ADEpt GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D

3 4

Performance Tuning & darcs (a real shootout?)
by Jason Dagit 24 Jan '06

24 Jan '06

Hello, This will be a long email so I've tried to give it sections. = Background = I've been using Haskell a while now (close to a year) and I'm still very much a newbie (but I've used other FP langs). I'm also very interested in darcs which, as many of you know, is written in Haskell. I've found a case which darcs does not handle efficiently and I'm trying to get the performance in that case to a satisfactory level. If you create a new repository, create a single large file (say 300mb) and record that file darcs will take a very long time and uses a lot of memory (usually at least 900mb for the 300mb case). Before I begin telling you what I've tried so far, let me give a brief history of previous efforts by others to optimize darcs. As far as I know, the main person to work on optimizing darcs in the past is Ian Lynagh. He was able to convert darcs from stricter algorithms to lazy ones and this made a huge improvement in performance. In theory darcs should be able to lazily read from a file, compute the patch that needs to be written, write that patch and then lazily read the patch while it is applied to the repository. This mostly works as expected, but I've discovered that somewhere near the end of the application the memory needed spikes dramatically. After almost two weeks of poking at darcs doing various benchmarks and profiles I've realized that optimizing Haskell programs is no easy task. I've been following the advice of numerous people from the haskell irc channel and learned a lot about darcs in the process. I've also been using this nifty library that Ian created for this purpose to get a measure for the non-mmap memory usage: http://urchin.earth.li/darcs/ian/memory Potentially useful information about darcs; 1) Uses a slightly modified version of FastPackedStrings. 2) Can use mmap or not to read files (compile time option). =Experiments and Findings= I have a summary of some of my experimentation with darcs here: http://codersbase.com/index.php/Darcs_performance Basically what I have found is that the read of the original file does not cause a spike in memory usage, nor does writing the patch. This would seem to imply that it's during application of the patch that the memory spikes. Modifying darcs to read the patch file and print just the first line of the patch causes some interesting results. The memory usage according to Ian's memory tool stays very low, at about 150kb max, but requesting the first line of the patch appears to make darcs read the entire patch! Darcs will literally grind away for, say, 30 minutes to just print the first line. On a side note, I've tried turing off mmap and running some of the above experiments. Ian's tool reports the same memory usage, and top still reports large amounts of memory used. Does ghc use mmap to allocate memory instead of malloc? Even if it does this shouldn't be a problem for Ian's tool as long as it maps it anonymously. =Questions= So far I've been tracking this performance problem by reading the output of ghc --show-iface and --ddump-simpl for strictness information, using the ghc profiler (although that makes already bad performance much worse), Ian's memory tool, and a lot of experiments and guess work with program modifications. Is there a better way? Are there tools or techniques that can help me understand why the memory consumption peaks when applying a patch? Is it foolish to think that lazy evaluation is the right approach? I've been thinking that perhaps darcs should be modified to use bounded buffers so that we have tight control over the amount of memory consumed during a run. This solution would require a lot of reworking of the existing code, and sounds frightful from a maintenance point of view. I'm also wondering if using mmap is a bad idea. Given the way files are currently mmap'd I think we are limiting darcs to handling files which are small enough to fit in the address space at once (eg., < 4GB on i386). Additionally, it would seem that using mmap does not really reduce memory stress. I'm looking for advice or help in optimizing darcs in this case. I guess this could be viewed as a challenge for people that felt like the micro benchmarks of the shootout were unfair to Haskell. Can we demonstrate that Haskell provides good performance in the real-world when working with large files? Ideally, darcs could easily work with a patch that is 10GB in size using only a few megs of ram if need be and doing so in about the time it takes read the file once or twice and gzip it. If anyone wants to look at the darcs code themselves the unstable version is available via: darcs get --partial http://abridgegame.org/repos/darcs-unstable Just to recap, I'm looking for 1) advice, 2) tips, 3) design ideas, 4) tools, 5) libraries and just about anything else :) Thanks, Jason

4 5

SDL on Mac
by Jake Luck 23 Jan '06

23 Jan '06

Anyone else here using the SDL binding on their Macs? (If memory serves me, at one point, I had gotten libSDL to work with 6.2.2). Now using GHC 6.4.1, while SDLstable-0.2.0 built without any problem for me on Linux, hsc2hs fails on the Mac: % runhaskell Setup.lhs build --verbose Reading parameters from /SDLstable/src/Core/SDL.buildinfo Preprocessing library SDL-0.2.0... /usr/local/bin/hsc2hs -I/fp/include/SDL -D_THREAD_SAFE -oGraphics/UI/SDL/General.hs Graphics/UI/SDL/General.hsc ld: Undefined symbols: _ZCMain_main_closure ___stginit_ZCMain % cat config.mk SDL_CFLAGS=-I/fp/include/SDL -D_THREAD_SAFE SDL_LIBS=-L/fp/lib -lSDLmain -lSDL -framework Cocoa -framework OpenGL PACKAGE=SDL VERSION=0.1.0 MAINTAINER%3Dlemmih(a)gmail.com % cat SDL.buildinfo cc-options: -I/fp/include/SDL -D_THREAD_SAFE ld-options: -L/fp/lib -lSDLmain -lSDL -framework Cocoa -framework OpenGL I am using the Mac OS X binary ghc 6.4.1 from the GHC download page on 10.4.3, linking to the latest libSDL 1.2.9 handbuilt with gcc 3.3. jake

1 0