- Haskell-Cafe - Haskell.org

ANNOUNCE: Guihaskell and PropLang 0.1
by Asumu Takikawa 15 Aug '07

15 Aug '07

Hello Haskellers. I'm one of the Google Summer of Code students for '07 and I'd like to announce the project my mentor, Neil Mitchell, and I have been working on. == GuiHaskell Guihaskell is a graphical REPL using PropLang, a GUI combinator library built on top of Gtk2hs, which aims to be an IDE for Haskell written in Haskell. It's still rough around the edges, so think of this as an alpha release. As such, I'd appreciate any feedback very much! Here's a feature list for 0.1: * Support for GHCi (default) and Hugs * Quick switching between compilers * Simple one-click profiling * Command history This first release of Guihaskell is mostly infrastructure. For future releases I aim to integrate more tools like Cabal and make it easier to use with an editor. == PropLang PropLang is a GUI library built on Gtk2hs that allows for high level design. The GUI is expressed as a series of relationships between GUI elements and data sources. Here's a "Hello World" example: import PropLang.Gtk import PropLang.Event main = do initPropLang window <- getWindow "foobar.glade" "wndFoo" let tb = getCtrl window "button" :: ToolButton tb!onClicked += putStrLn "Hello World!" showWindowMain window This example prints "Hello World!" when the user presses a button defined in a Glade file. PropLang is used with glade to define the interface. You can define more complicated relationships using the combinators in PropLang.Variable. Here's a snippet from GuiHaskell: tie (txtSelect!text) filename (\t -> if null t then Nothing else Just t) (maybe "" id) "tie" takes two PropLang variables and relates them so that when one is updated, it will inject its value into another. It also takes two functions to run on the data before injection. This snippet is used to tie the representation of the currently selected file in GuiHaskell (a Maybe String) to Gtk's TextView buffer (a String). If you injected a new value into filename... filename -< Nothing then txtSelect's text buffer would be set to "". You can also build other behaviors into PropLang variables to do interesting things. GuiHaskell has a configuration API built around PropLang. Configuration items are defined as special PropLang variables: filename <- newVarWithName "selected_filename" (newConfValueWithDefault Nothing "selected_filename") "newVarWithName" in PropLang.Variable lets you make new variables with custom actions to retrieve and set values. "newConfValue" is defined in GuiHaskell to serialize configuration items to disk so they can be read back after closing the program. For more information you can generate the Proplang docs with haddock. == Install Get the packages here: http://hackage.haskell.org/packages/archive/GuiHaskell/0.1/GuiHaskell-0.1.t… http://hackage.haskell.org/packages/archive/proplang/0.1/proplang-0.1.tar.gz Install with cabal: runhaskell Setup.lhs configure runhaskell Setup.lhs build runhaskell Setup.lhs install == You can send feedback to my e-mail, the list, or contact me on IRC (I'm Shimei on #haskell). Thanks. Cheers, Asumu Takikawa

3 2

ANN: HAppS-Data 0.9: XML, Pairs, HList, deriveAll
by Alex Jacobson 15 Aug '07

15 Aug '07

We've refactored the happs repos and are now going to releasing components of HAppS as individual useful packages. HAppS-Data is the first one. Don't pull a tag, pull the most recent stuff in the repos. --- HAppS-Data v0.9: XML, Name/Value Pairs, HList, deriveAll * toXml and fromXml transform your haskell values to and from XML. Declare your own instances of class Xml to customize the Xml representation. * toPairs and fromPairs transform haskell values to and from name-value pairs (e.g. for url-encoded data). Pairs are converted between xpath expressions. Use toPairsX if you want a conversion without the top level constructor, fromPairs can handle that as long as your type has only one top level constructor. * toHTMLForms to produce an HTML forms representation of your data that can be consumed by fromPairs in a urldecoding context. toHTMLForms uses toPairsX for shorter input field names. * $(deriveAll) to batch derive Default and as well as the standard derivable without all the boring per data "deriving" declarations * Default missing values by declaring your own instances of class Default or have default values derived autotomatically. * Normalize your values by declaring your own instance of class Normalize. * Type safe easy-to-use heterogenous collections. t1 .&. t2 .&. t3 are a heterogenous lists of values. (HasT hlist t) is a class constraint to that the hlist contains a particular type. (x hlist)::t obtains a value of type t from inside the hlist. (u hlist v) updates the hlist with the value v if the hlist has type. x and u return compile time errors if the type is not inside the hlist. fromPairs is currently broken for hlist. darcs get http://happs.org/HAppS/HAppS-Data

1 0

Monad explanation from a newbie to newbies having C# (or other OO) experience
by Peter Verswyvelen 15 Aug '07

15 Aug '07

See attachment. This is an early draft, but I’m afraid it will just be another tutorial that does not solve anything, so I’ll better throw it in the arena for review right now, so I don't waste more time ;-) The idea of this tutorial is not explaining monads, bet getting to the monad concept step by step, and then finally in the end talking about the real monad abstraction. Note that I’m a self-made man, so much of the terminology and even approach could be wrong (I learned it adhoc). I also hardly have any Haskell experience (maybe 5 full days of writing example code now), but anyway, writing this tutorial was a good exercise. To make things even worse I’m also not a native English speaker, so it will most likely be some kind of Belgian English (without the chocolate) ;) So horror is coming your way! Any feedback is welcome! ☺ Cheers, Peter

1 0

Re: Bathroom reading
by Chad Scherrer 15 Aug '07

15 Aug '07

Maybe something of these? http://www.haskell.org/haskellwiki/Blow_your_mind -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

1 0

Converting Emacs syntax coloured Haskell code to HTML
by Peter Verswyvelen 14 Aug '07

14 Aug '07

I noticed many code snippets on the wiki that have syntax colouring. How is this done? Can I convert syntax coloured code from Emacs to HTML? I'm using the Haskell mode for Emacs to get the syntax colouring. I'm writing a "monads for C# programmers tutorial" (oh nooooooooo) and would like to use this feature. Of course I won't publish this tutorial before sending it to this mailing list, because when a newbie writes a tutorial, it is usually a disaster ;-) But the feedback I get from this community is super handy (that is when it is not PhD talk which I don't understand ;), so I guess comments on this tutorial will give me a better understanding. Thanks, Peter

3 2

Explaining monads
by Brian Brunswick 14 Aug '07

14 Aug '07

(Better view the below in a fixed-width font!) With all the recent monad discussions, I embarked on trying to clarify my own thoughts about them, and started to think about things in terms of just /where/ extra structure is 'understood'. I think I can explain why 'a->IO b' is better than 'IO a->b'. The full title of this is really 'Explaining monads by comparison with comonads and arrows', but I didn't want to scare people off without putting in the above hook! We start with a simple single value of type 'a', and then we move into some other category, where the objects are 'thing a' instead, encapsulating some additional complexity - perhaps the possible absence or multiplicity of the value, perhaps extra state, opacity, etc. But whatever it is, the a-ness is still key for combing these objects. So lets look how they combine. Pay special attention to the f column. g f ??? g ??? f application a a->b flip ($) b monad bind m a a->m b >>= m b comonad cobind w a w a->b =>> w b arrow arr a b arr b c >>> arr a c simple application: f takes one argument, returns one result. monad: f still takes one argument, but now understands how to put things /into/ m. (Perhaps it just uses return::a->m a) comonad: f has access to the entire complexity of 'w a', understands how to get thing(s) out of it (coreturn), and distills it all down to one simple b. arrow: f has access to the entire complexity of the 'input' of arr b c, and does whatever is needed, to make the complexity of the 'output' of arr b c. Input/output may even be bidirectional! Also we can look at the job that ??? does. Remember that ??? has access to f as a function and can call it as many or as few times as it wishes. $: feeds a to f, once. >>=: picks zero or more a's from 'm a', feeds each one separately to f. opens up each of the 'm b' results to combine them into one 'm b'. =>>: feeds one or more versions of 'w a' to f, then builds a 'w b' in some way using the single b's (Perhaps inspired by 'w a') >>>: links g to f in some way, so they can interact in as complex a way as they like. Maybe it also contributes to that complexity. So now perhaps we can come to some conclusion about why monads are so useful and universal as control structures. It seems that monads are somehow the /simplest/ way of adding general control structure on top of single values. Notice how in a monad, the things that are combined together, the f's, still take just one 'a' argument. So theres no extra complexity for f in understanding its input. f can, however, put some additional complexity into its output - it can fail, or return multiple values, or whatever else is possible to encode in 'm a'. Still, f can be dumb, and just pass the problem onto some other function, maybe return. The complexity of the monad lives in one place, bind, >>=. It is bind that has the choice of calling f multiple times if it feels like it, and has the job of combining the results. bind is in control. f can only give it directions by returning one 'm b' for a given a. Contrast a comonad. Each f has to cope with an entire 'w a' on input. Moreover, it can't communicate any of that complexity back to cobind - it can only return one b. cobind only has the structure of 'w a' to inspire it in how to put together 'w b', it can receive /no/ instructions from f. Arrows are of course most general. Nothing is determined except that f talks with g in some way, and the compatibility is named 'b'. So given the choice of the above, which would /you/ choose, when the nature of the problem means one-on-one application is too simple? Surely a monad is the pick of the bunch! * f gives merely directions on control to >>= * f has to understand merely one single argument. (the monad can supply extra specialized functions like get/put, if we do want some complexity in there) * All the complex control structure is handled in one place - bind. And it has all the information available to do it well. Pity the poor comonad, only really suitable for infinite sequences! Shudder at the thought of the total complexity possible using arrows, and use them only when /really/ necessary. monad is king! -- Brian_Brunswick____brian@ithil.org____Wit____Disclaimer____!Shortsig_rules!

16 27

Parsec: Parenthesized expressions and more!
by Vimal 14 Aug '07

14 Aug '07

Hi I was trying out some parsing with parsec. I tried: Accepting proper parenthesized expressions, this was the code: parens :: Parser () parens = do char '(' parens char ')' parens <|> return () Implementing basically: S -> (S)S | e. I doubt the fact that 'e' was actually considered, because the program seems to be accepting all strings of the form ())*. Did I go wrong somewhere? I guess this could be because, the input was "partially" accepted. Can I force it to derive the entire input string? And, btw, is there a method to implement an epsilon production? I tried do { string "" ; rules ... } And it didn't seem to work. I am also trying out this problem just for fun, but I seem to be getting wrong answers! http://spoj.pl/problems/FOOL Maybe I implemented something wrong. So, i will wait for some comments on the above parsing, and try one more time before I ask questions on that :D Cheers -- -- Vimal Department of Computer Science and Engineering Indian Institute of Technology Madras

2 1

a regressive view of support for imperative programming in Haskell
by Paul Hudak 14 Aug '07

14 Aug '07

All of the recent talk of support for imperative programming in Haskell makes me really nervous. To be honest, I've always been a bit uncomfortable even with monad syntax. Instead of: do x <- cmd1 y <- cmd2 ... return e I was always perfectly happy with: cmd1 >>= \x-> cmd2 >>= \y-> ... return e Functions are in my comfort zone; syntax that hides them takes me out of my comfort zone. In my opinion one of the key principles in the design of Haskell has been the insistence on purity. It is arguably what led the Haskell designers to "discover" the monadic solution to IO, and is more generally what inspired many researchers to "discover" purely functional solutions to many seemingly imperative problems. With references and mutable data structures and IO and who-knows-what-else to support the Imperative Way, this discovery process becomes stunted. Well, you could argue, monad syntax is what really made Haskell become more accepted by the masses, and you may be right (although perhaps Simon's extraordinary performance at OSCOM is more of what we need). On the other hand, if we give imperative programmers the tools to do all the things they are used to doing in C++, then we will be depriving them of the joys of programming in the Functional Way. How many times have we seen responses to newbie posts along the lines of, "That's how you'd do it in C++, but in Haskell here's a better way...". I hope I don't start a flame war with this post -- I'm just expressing my opinion, which admittedly is probably regressive rather than progressive :-). -Paul -- Professor Paul Hudak Department of Computer Science Office: (203) 432-1235 Yale University FAX: (203) 432-0593 P.O. Box 208285 email: paul.hudak(a)yale.edu New Haven, CT 06520-8285 WWW: www.cs.yale.edu/~hudak

21 33

Small proof intro
by Tim Newsham 14 Aug '07

14 Aug '07

I put together a small intro lesson on proving haskell code using quickcheck, equational reasoning and Isabelle/HOL. Its very elementary, but might be of interest to some people here. http://www.thenewsh.com/%7Enewsham/formal/reverse/ Feedback is appreciated. Tim Newsham http://www.thenewsh.com/~newsham/

1 0

A few questions on primes generating.
by L.Guo 14 Aug '07

14 Aug '07

Hi All: I am reading http://www.haskell.org/haskellwiki/Prime_numbers The code in sector "1 Bitwise prime sieve". I have 3 questions about it. 1) In function go, what does the number 46340 mean ? Is it sqrt(MAX_LONG) ? 2) We have this type definition : pureSieve :: Int -> Int Why there is no error (type mismatch) of this call in func main : pureSieve 10000000 3) In main again, what does expression [| x |] mean ? Why this cannot be execute in GHCi ? Thanks for any advice. Regards -------------- L.Guo 2007-08-13

8 9