August 2007 - Haskell-Cafe

Re: [Haskell-cafe] Why monad tutorials don't work
by Dan Piponi 15 Aug '07

15 Aug '07

On 8/14/07, Dan Weston <westondan(a)imageworks.com> wrote: > Conor McBride and Ross Paterson said it best in the introduction to > their paper "Applicative programming with effects" [1]: As von Neumann said: "Young man, in mathematics you don't understand things, you just get used to them." Getting used to something is, practically by definition, something that you can't do just by reading the ultimate tutorial. You just have to write the code, see the pattern happen again and again, and abstract it. There's no short cut. (Well...sometimes...) On 8/14/07, Michael Vanier <mvanier(a)cs.caltech.edu> wrote: > I'm reminded of > a physics teacher who was having a similar problem explaining the concept of tensors, until he said > that "a tensor is something that transforms like a tensor does!". Grrr...must...hold...my...tongue... -- Dan

8 10

Re: [Haskell-cafe] monte carlo trouble
by Chad Scherrer 15 Aug '07

15 Aug '07

Funny you should say that, I was just experimenting with generating one at a time using (StateT StdGen Maybe). If I get stuck (again) I'll check out ListT. Thanks! Chad On 8/15/07, Paul Johnson <paul(a)cogito.org.uk> wrote: > Chad Scherrer wrote: > > Thanks for your replies. > > > > I actually starting out returning a single element instead. But a > > given lookup might return [], and the only way I could think of to > > handle it in (State StdGen a) would be to fail in the monad. But > > that's not really the effect I want - I'd rather have it ignore that > > element. Another option was to wrap with Maybe, but then since I > > really want a sequence of them anyway, I decided to just wrap in a > > List instead. Is there a way Maybe would work out better? > Ahh. How about using ListT Gen then? That (if I've got it the right > way round) works like the list monad (giving you non-determinism), but > has your random number generator embedded as well. Take a look at "All > About Monads" at http://www.haskell.org/all_about_monads/html/. Each > action in the monad may use a random number and produce zero or more > results. > > Paul. -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

1 0

Re:Explaining monads
by Gregory Propf 15 Aug '07

15 Aug '07

Sorry to spam you Jeff, again I sent my email to the poster rather than the list. I'm using Yahoo beta webmail and don't see a way to set it to reply to the list rather than the originator. Anyway, this was my post: Hence the need to perform a "run" operation like runIdentity, evalState or runParser (for Parsec) to get something useful to happen. Except for lists we don't seem to do this. I suppose lists are so simple that the operators :, ++ and the [] constructor do all we ever need with them. Finally there is no runIO because "main" is essentially that function in every real program? - Greg ----- Original Message ---- From: Jeff Polakow <jeff.polakow(a)db.com> To: lanny(a)cisco.com Cc: haskell-cafe-bounces(a)haskell.org; Haskell-Cafe <haskell-cafe(a)haskell.org> Sent: Tuesday, August 14, 2007 8:45:06 AM Subject: Re: [Haskell-cafe] Explaining monads One general intuition about monads is that they represent computations rather than simple (already computed) values: Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. ____________________________________________________________________________________ Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222

3 2

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 14 Aug '07

14 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 14 Aug '07

14 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(a)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