February 2009 - Haskell-Cafe

ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Jul '09

17 Jul '09

Dear friends of Haskell and Functional Reactive Programming, its my pleasure to announce the first official release of Grapefruit, a library for Functional Reactive Programming (FRP) with a focus on user interfaces. With Grapefruit, you can implement reactive and interactive systems in a declarative style. User interfaces are described as networks of communicating widgets and windows. Communication is done via different kinds of signals which describe temporal behavior. Grapefruit consists of five packages with several interesting features: grapefruit-frp: Functional Reactive Programming core * The FRP implementation uses a hybrid push/pull-based approach. * Signals can be memoized by binding them to variables – like ordinary data structures. * Merging of event streams combines simultaneous events properly. * Signals cannot behave differently by starting them at different times. The type system is used to enforce proper aging of signals. grapefruit-records: A record system for Functional Reactive Programming * Input records can specify fields as being required or optional. * Uninteresting output fields can be ignored. The set of interesting fields is specified by pattern matching. grapefruit-ui: Declarative user interface programming * The interface for UI programming is platform-independent and can be implemented on top of different UI toolkits. * A concrete implementation can be selected at compile time or runtime. grapefruit-ui-gtk: GTK+-based implementation of the general UI interface * Gtk2Hs is used internally. grapefruit-examples: examples demonstrating features of Grapefruit * Circular communication and switching are demonstrated. Support for the following is planned for the future: * signals with incremental updates * user interfaces with changing structure * more kinds of UI components * graphical animations Further information about Grapefruit is available on its wiki page at <http://haskell.org/haskellwiki/Grapefruit>. If you have questions, applause or criticism, please get in touch with me. Wolfgang Jeltsch Principal Grapefruit developer

6 10

Re: [Haskell] ANNOUNCE: first Grapefruit release
by Wolfgang Jeltsch 17 Jul '09

17 Jul '09

[redirecting to haskell-cafe] Am Sonntag, 15. Februar 2009 00:25 schrieben Sie: > Hi Wolfgang, > > I was wondering if I can use FLTK as GUI backend for Grapefruit? This should be possible in principal. It just could be that my assumptions about how widgets are created and composed were too tight so that Grapefruit’s general interface doesn’t fit FLTK. In this case, please just tell me and I will try to make the interface more general. > I believe for this to make it happen, I would have to output FLTK's C++ > into C then create bindings for Haskell (via FFI). Is that doable or an > quite tall order? Recently, a student of mine has written a program which generates a Haskell Qt binding fully automatically from Qt header files. The generated binding consists of three layers. The first layer is C++ code which reexports Qt’s functionality as a pure C interface. The C interface is ugly for humans and not type safe (because C doesn’t know classes). The second layer consists of a couple of FFI declarations. The third layer is Haskell code which provides a nice interface similar to the original C++ interface. I still have to get the source code of the binding generator from that student but I hope this will happen soon. I want to publish it then on the web. It hope that it is possible to reuse this binding generator for other C++ libraries. > Jamie Clark Best wishes, Wolfgang

2 2

[Haskell] ANNOUNCE: ChristmasTree 0.1 (excuses for second attempt)
by S.Doaitse Swierstra 07 Jul '09

07 Jul '09

We are pleased to announce the availability of the package "ChristmasTree", which contains the code associated with our paper at the last Haskell symposium: @inproceedings{1411296, author = {Marcos Viera and S. Doaitse Swierstra and Eelco Lempsink}, title = {Haskell, do you read me?: constructing and composing efficient top-down parsers at runtime}, booktitle = {Haskell '08: Proceedings of the first ACM SIGPLAN symposium on Haskell}, year = {2008}, isbn = {978-1-60558-064-7}, pages = {63--74}, location = {Victoria, BC, Canada}, doi = {http://doi.acm.org/10.1145/1411286.1411296}, publisher = {ACM}, address = {New York, NY, USA}, } The name of the package stands for: "Changing Haskell's Read Implementation Such That by Manipulating Abstract Syntax Trees it Reads Expressions Efficiently" which, given the time of year, seems appropriate. Feel free to download and unpack this "present" at what for the Dutch is called "Sinterklaasavond" (http://en.wikipedia.org/wiki/Sinterklaas) Arthur Baars Marcos Viera Eelco Lempsink Doaitse Swierstra PS: the package uses our library supporting transformation of typed abstract syntax, which we placed in a separate package TTTAS

2 1

I love purity, but it's killing me.
by Tom Hawkins 09 Jun '09

09 Jun '09

I've been programming with Haskell for a few years and love it. One of my favorite applications of Haskell is using for domain specific languages. However, after designing a handful of DSLs, I continue to hit what appears to be a fundamental hurdle -- or at least I have yet to find an adequate solution. My DSLs invariably define a datatype to capture expressions; something like this: data Expression = Add Expression Expression | Sub Expression Expression | Variable String | Constant Int deriving Eq Using the datatype Expression, it is easy to mass a collections of functions to help assemble complex expressions, which leads to very concise programs in the DSL. The problem comes when I want to generate efficient code from an Expression (ie. to C or some other target language). The method I use invovles converting the tree of subexpressions into an acyclic graphic to eliminate common subexpressions. The nodes are then topologically ordered and assigned an instruction, or statement for each node. For example: let a = Add (Constant 10) (Variable "i1") b = Sub (Variable "i2") (Constant 2) c = Add a b would compile to a C program that may look like this: a = 10 + i1; b = i2 - 2; c = a + b; The process of converting an expression tree to a graph uses either Eq or Ord (either derived or a custom instance) to search and build a set of unique nodes to be ordered for execution. In this case "a", then "b", then "c". The problem is expressions often have shared, equivalent subnodes, which dramatically grows the size of the tree. For example: let d = Add c c e = Add d d -- "e" now as 16 leaf nodes. As these trees grow in size, the equality comparison in graph construction quickly becomes the bottleneck for DSL compilation. What's worse, the phase transition from tractable to intractable is very sharp. In one of my DSL programs, I made a seemingly small change, and compilation time went from milliseconds to not-in-a-million-years. Prior to Haskell, I wrote a few DSLs in OCaml. I didn't have this problem in OCaml because each "let" expression was mutable, and I could use the physical equality operator to perform fast comparisons. Unfortunately, I have grown to love Haskell's type system and its lack of side effects, and could never go back. Is there anything that can be done to dramatically speed up comparisons, or is there a better approach I can take to extract common subexpressions? I should point out I have an opportunity to get Haskell on a real industrial application. But if I can't solve this problem, I may have to resort to far less eloquent languages. :-( Thanks for any and all help. -Tom

17 36

Template Haskell very wordy w/r/t Decs and Types
by Ross Mellgren 28 May '09

28 May '09

Hi all, I'm writing a small module that exposes a template haskell splice that takes a (very simplified) C struct definition and builds: - A data type definition, - an instance for Data.Binary.Binary, - and optionally a pretty print function for it However, it seems to do this I have to write a bunch of really ugly code that builds up the TH data structures "by hand" because quoting only works with splices for expressions, or so it seems. For example, to generate the binary instance I have this code: import qualified Language.Haskell.TH as TH -- tyname is the name of the data type I've already created, as a TH.Name -- tempnames is a list of temporary variable names that are used in lambda patterns -- fields is a list of tuples describing each field -- makeGetExp recursively builds a monadic computation consisting mostly of Binary.getWord32be >>= \ tempvar -> ... binaryInstDec <- liftM (TH.InstanceD [] (TH.AppT (TH.ConT $ TH.mkName "Data.Binary.Binary") (TH.ConT tyname))) [d| get = $(makeGetExp (reverse $ zip fields tempnames) returnExp) put = undefined |] I'd really rather write: binaryInstDec <- [d| instance Binary.Binary $(tyname) where get = $(makeGetExp (reverse $ zip fields tempnames) returnExp) put = undefined |] But GHC gives me a syntax error on the tyname splice. The docs seem to indicate this is the way it is -- that splices in type locations is plain not implemented. My question is whether or not this is just the way it is, and people writing TH declaration splices tend to have to start manually assembling a bunch of it, or is there some trick I've missed? Perhaps even better are there some tricks that people tend to use to make this less painful? I did try using some of the lowercased monadic constructors in Language.Haskell.TH.Lib but I didn't seem to get anything more succint out of it. -Ross P.S. This is for a one-off weekend project, and the code is fugly, so I'm not posting it in its entirety here. If you want the whole module and are willing not to laugh, I'd be glad to send it along ;-) Background: I'm doing this because I'm writing a tool to snoop around the filesystem structures of HFS+ to try and help a friend recover some data off a sufficiently dead drive that fsck doesn't want to touch it, and I don't want to pay money just to find out the drive is too toasty to pull out the data. In any case, the HFS+ docs have a bunch of C struct definitions that comprise the structures, and I got tired of hand-writing data definitions and binary instances, so I figured I'd make TH do it for me.

4 4

Lazy vs correct IO [Was: A round of golf]
by oleg＠okmij.org 06 Apr '09

06 Apr '09

Lennart Augustsson wrote > main = do > name:_ <- getArgs > file <- readFile name > print $ length $ lines file Given the stance against top-level mutable variables, I have not expected to see this Lazy IO code. After all, what could be more against the spirit of Haskell than a `pure' function with observable side effects. With Lazy IO, one indeed has to choose between correctness and performance. The appearance of such code is especially strange after the evidence of deadlocks with Lazy IO, presented on this list less than a month ago. Let alone unpredictable resource usage and reliance on finalizers to close files (forgetting that GHC does not guarantee that finalizers will be run at all). Is there an alternative? -- Counting the lines in a file import IterateeM count_nl = liftI $ IE_cont (step 0) where step acc (Chunk str) = liftI $ IE_cont (step $! acc + count str) step acc stream = liftI $ IE_done acc stream count [] = 0 count ('\n':str) = succ $! count str count (_:str) = count str main = do name:_ <- getArgs IE_done counter _ <- unIM $ enum_file name >. enum_eof ==<< count_nl print counter The function count_nl could have been in the library, but I'm a minimalist. It is written in a declarative rather than imperative style, and one easily sees what it does. The above code as well as the IterateeM library is Haskell98. It does not use any unsafe Haskell functions whatsoever. time wc -l /usr/share/dict/words 235882 /usr/share/dict/words real 0m0.024s user 0m0.022s sys 0m0.000s time ~/Docs/papers/DEFUN08/Wc /usr/share/dict/words 235882 real 0m0.141s user 0m0.126s sys 0m0.008s To compare with lazy IO, the code using readFile gives time ~/Docs/papers/DEFUN08/Wc /usr/share/dict/words 235882 real 0m0.297s user 0m0.262s sys 0m0.023s So, choosing correctness does not mean losing in performance; in fact, one may even gain. Can enumerators compose? Well, we already seen the example above (enum_file name >. enum_eof) where the operation (>.) e1 >. e2 = (==<<) e2 . e1 is a flipped composition if monadic bind were considered a flipped application. Here is a more interesting example: count words in all the files whose names are given on the command line. There may be many files given, thousands of them. -- Count the stream. Again, could have been in the library stream_count :: Monad m => IterateeGM el m Int stream_count = liftI $ IE_cont (step 0) where step acc (Chunk []) = liftI $ IE_cont (step acc) step acc (Chunk [_]) = liftI $ IE_cont (step $! succ acc) step acc (Chunk ls) = liftI $ IE_cont (step $! acc + length ls) step acc stream = liftI $ IE_done acc stream main = do names <- getArgs let enumerators = foldr (\name -> (enum_file name >.)) enum_eof names IE_done (IE_done counter _) _ <- unIM $ enumerators ==<< enum_words stream_count print counter We notice that the composition of enumerators corresponds to the `concatenation' of their sources. Declaratively, the meaning of the above code is: -- all the given files are concatenated -- the resulting stream of characters is converted to a stream of words -- the stream of words is counted. Operationally, the code does not open more than one file at a time. More importantly, the code *never* reads more than 4096 characters at a time. A block of the file is read, split into words, counted, and only then another chunk is read. After one file is done, it is closed, and another file is processed. One can see that only one file is being opened at a time by enabling traces. The processing is fully incremental. /usr/local/share/doc/ghc6> find . -name \*.html -print | time xargs ~/Docs/papers/DEFUN08/Wc 3043421 16.99 real 15.83 user 0.71 sys BTW, the program has counted words in 1169 files. It is interesting to compare the above main function with the corresponding lazy IO: main'' = do names <- getArgs files <- mapM readFile names print $ length $ words (concat files) The number of lines is comparable. The execution is not. If we try to run the lazy IO code, we get: /usr/local/share/doc/ghc6> find . -name \*.html -print | time xargs ~/Docs/papers/DEFUN08/Wc Wc: ./libraries/Win32/Graphics-Win32-GDI-Path.html: openFile: resource exhausted (Too many open files)

9 12

what does "atomically#" mean?
by Daryoush Mehrtash 20 Mar '09

20 Mar '09

Any idea was the atomically# mean in the following code? atomically :: STM a -> IO a atomically (STM m) = IO (\s -> (*atomically# *m) s ) Code is from GHC.Conc module http://www.haskell.org/ghc/docs/6.6/html/libraries/base/GHC-Conc.html daryoush

4 5

Using cabal to build an exportable library?
by Justin Bailey 20 Mar '09

20 Mar '09

I've been following this instructions at http://www.haskell.org/haskellwiki/Calling_Haskell_from_C to build a Haskell library which I can call from a C program. I'd like to use cabal to do the build in the future. Are there any examples showing how to do it?

2 1

Proposal for associated type synonyms in Template Haskell
by Thomas van Noort 19 Mar '09

19 Mar '09

Hello, Recently, we released a library on Hackage for generic rewriting (package "rewriting" if you are curious). The user of the library is expected to define type class instances to enable rewriting on his or her own datatypes. As these instances follow the datatype declarations closely, we tried to generate the instances using Template Haskell. Unfortunately, associated type synonyms are not yet supported by TH. After a presentation at the WGP'08, Simon encouraged us to write a proposal about adding associated type synonyms to TH, so that it can be added to GHC. So, here is our proposal. The TH AST must allow 1) kind declarations of associated type synonyms in class declarations and 2) their definitions in instance declarations. For example, class Foo a where type Bar a :: * instance Foo Int where type Bar Int = String The TH library defines a datatype Dec which contains a constructor for class declarations and instance declarations: data Dec = ... | ClassD Cxt Name [Name] [FunDep] [Dec] | InstanceD Cxt Type [Dec] ... 1) Associated type synonym kind declarations We suggest to add a constructor to the Dec type: ... | AssocTySynKindD Name [Name] (Maybe Kind) ... assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ The first field is the name of the associated type synonym, the second field is a list of type variables, and the third field is an optional kind. Since kinds are not yet defined in TH, we have to add some kind of kind definition (pun intended): data Kind = StarK | ArrowK Kind Kind type KindQ = Q Kind starK :: KindQ arrowK :: KindQ -> KindQ -> KindQ We explicitly choose not to reuse the Type type to define kinds (i.e., type Kind = Type as in GHC) since we think a separation between the two worlds is much clearer to the users of TH. 2) Associated type synonym definitions We suggest to add another constructor to the Dec type: ... | AssocTySynD Name [Type] Type ... assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ The first field is the name of the type synonym, the second field is a list of type arguments, and the third field is the body of the type synonym. We would like to hear your comments to this proposal. Regards, Thomas

5 5

What *not* to use Haskell for
by Dave Tapley 19 Mar '09

19 Mar '09

Hi everyone So I should clarify I'm not a troll and do "see the Haskell light". But one thing I can never answer when preaching to others is "what does Haskell not do well?" Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Cheers, Dave

39 82