May 2009 - Haskell-Cafe

monad . comonad = id
by Jan Christiansen 08 May '09

08 May '09

Hi, I have a question regarding the connection between monads and comonads. I always thought of the comonad operations as being the inverse operations of the corresponding monad functions. As I do not know the underlying theory I thought I simply ask the masters. Is there a formal verification for this intuition? That is, are there always corresponding instances for monad and comonad such that the following laws are satisfied? extract . return == id join . duplicate == id If this is the case I would like to know what the corresponding monad for the following comond could be. This comonad treats lists as pointed sets where the first element is focused. instance Comonad [] where extract = head duplicate xs = init (zipWith (++) (tails xs) (inits xs)) Obviously we can define return x = [x]. But I do not know how to define join. Cheers, Jan

3 4

Curry and Reader monad
by Daryoush Mehrtash 08 May '09

08 May '09

In the Is currying monadic?<http://greenokapi.net/blog/2009/05/07/is-currying-monadic/>post the author says: This is again a nested expression. So I wondered if you could again > "flatten" it with a monadic do block: > > let add3 = do > a <- get first parameter > b <- get second parameter > c <- get third parameter > > > return a+b+c > > OK, so I "know" that functions in Haskell (which uses currying for > functions as a general rule) are the "Reader monad". But I don't understand > it well enough to know if that means you can use Reader to implement the > above... > > (I don't understand Reader at all in fact. I must bang my head against it > again, but I find it very confusing - how the monad is represented, what the > functions are, and how they get magically applied.) > Any idea what he is talking about? Thanks Daryoush

2 1

How difficult would creating a collaborative multi-user online virtual world application be in Haskell?
by Benjamin L.Russell 07 May '09

07 May '09

One question that has been coming up at the back of my mind for the past several weeks has been how difficult would it be to create a collaborative multi-user online virtual world application in Haskell. More specifically, last August, I came across a very interesting application called Croquet (see http://www.opencroquet.org/index.php/Main_Page) which happens to be based on Squeak (see http://www.squeak.org/) a dialect of Smalltalk. Croquet, in turn, provides the basis for Cobalt (see http://www.duke.edu/~julian/Cobalt/Home.html) a "virtual workspace browser and construction toolkit for accessing, creating, and publishing hyperlinked multi-user virtual environments" (according to the home page for that project). What struck me as especially interesting was how Croquet allows multiple users to collaborate together in a multi-user online virtual world in software development and other collaborative projects. As one application, the video clip on the upper-right-hand corner of the above-mentioned Croquet home page illustrates how a user can, by writing code from inside the application, create on-the-fly additional virtual environments, which can then be entered by either the programmer or other programmers. Other applications (shown in other video clips on the "Screenshots/Videos" page (see http://www.opencroquet.org/index.php/Screenshots/Videos) show alternative applications that include text-based annotations, a 3D spreadsheet, and writing a conventional blog from within a virtual world. Unfortunately, Smalltalk is an object-oriented language. If possible, I would like to see something similar in a functional programming language such as Haskell. Does anybody know whether duplicating this project in Haskell would be feasible? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 "Furuike ya, kawazu tobikomu mizu no oto." -- Matsuo Basho^

4 3

Visualizing Typed Functions
by Duane Johnson 07 May '09

07 May '09

I'm not sure what the policy is on posting with graphical attachments, but I'll give this a tentative try. In case this does not come through with images, I've also posted this on my blog at http://blog.inquirylabs.com/2009/05/07/visualizing-typed-functions/ ===== As I've worked in Haskell over the past several months, I've noticed that my mind has kind of implicitly modeled functional programming as a visual/mechanical representation of concepts. I'd like to make the ideas more explicit, however, so I'm writing this post and cooking up some graphics. I wonder if others have similar "internal representations" of functions, and if perhaps others might suggest improvements over my model. The basic idea is that a function is a semi-circle with inputs on one side (left) and the output at the right. Colors represent types. Here is a function that takes one input and produces one output (of the same type): Haskell would type this as "a -> a". Next, we have a function that takes one type and returns a different type... e.g. a hashing function might take a string and return an integer: (Please ignore the vertical stripe, it's an artifact of my poor Inkscape skills). We can also create functions with more than one input, of course, so here is a binary function. It might be the '+' operator, or some other binary operator, e.g. "a -> a -> a": Haskell and many other languages also have the concept of higher-order functions, i.e. functions that take functions as inputs. Here is a binary function that takes a binary function as input, along with another input, to produce an output of the same type: I imagine polymorphic types as "banded colors" so that the bands contain another type (color). Lists are polymorphic types. Here is what the "head" function might look like ("head" returns the first element in a list): Finally, here is a composite of all of the above visualizations. The "map" function in Haskell is a function that takes a function and a list, and applies that function to each element in the list, returning a new list with the "mapped" elements: The type signature for the "map" function is "(a -> b) -> [a] -> [b]". I wonder what a Monad would look like... With these functions visualized, one could make a kind of "drag and drop" interface for Haskell programming, although that isn't really my intention. I admit this is a little convoluted even for the purpose of visualization, but at least it's a starting place. Does anyone know of another system or better representation?

6 7

ANNOUNCE: The Haskell Platform
by Don Stewart 07 May '09

07 May '09

We're pleased to announce the first release of the Haskell Platform: a single, standard Haskell distribution for every system. Download the Haskell Platform 2009.2.0 installers and specification: http://hackage.haskell.org/platform/ The Haskell Platform is a blessed library and tool suite for Haskell culled from Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. What you get: http://hackage.haskell.org/platform/contents.html With regular time-based releases, we expect the platform will grow into a rich, indispensable development environment for all Haskell projects. Distro maintainers that support the Haskell Platform can be confident they're fully supporting Haskell as the developers intend it. Developers targetting the platform can be confident they have a trusted base of code to work with. *Please note that this is a beta release*. We do not expect all the installers to work perfectly, nor every developer need met, and we would appreciate feedback. You can help out by packaging the platform for your distro, or reporting bugs and feature requests, or installing Haskell onto your friends' machines. The process for adding new tools and libraries will be outlined in coming weeks. The Haskell Platform would not have been possible without the hard work of the Cabal development team, the Hackage developers and maintainers, the individual compiler, tool and library authors who contributed to the suite, and the distro maintainers who build and distribute the Haskell Platform. Thanks! -- The Platform Infrastructure Team

2 2

beginner question: assigning local variable to a function
by Nico Rolle 07 May '09

07 May '09

hi why does this don't work? test = let a = (>) in 1 `a` 2 regards

4 6

GLFW - Mac OS X
by Günther Schmidt 07 May '09

07 May '09

Hi, has anybody recently install the GLFW package on Mac OS X? It won't install on my machine. Günther

3 2

Trying to contact authors of "Real World Haskell"?
by Itsme (Sophie) 07 May '09

07 May '09

I could not find any contact info for Brian O'Sullivan, Don Stewart, or John Goerzen on their book site. Any pointers to how I might locate any of them much appreciated. Thanks! Sophie

7 8

Getting WriterT log lazily
by Magnus Therning 07 May '09

07 May '09

I've been playing around with (WriterT [Int] IO), trying to get the log out and map `print` over it... and do it lazily. However, I'm not really happy with what I have so far, since I've had to resort to `unsafePerformIO`. Any hints are welcome. What I have so far is: foo = let _tell i = do a <- return $ unsafePerformIO $ sleep 1 tell [a + 1 `seq` i] in do mapM_ _tell [1..10] main = do (_, ~res) <- runWriterT foo mapM_ print res Without the `seq` the call to sleep will simply be skipped (is there an easier way to force evaluation there?). Without `unsafePerformIO` all the sleeping is done up front, and all numbers are print at once at the end. The goal is of course to use code along the same shape to do something more useful, and then `unsafePerformIO` will really be unsafe... /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

5 7

Operator precedence and associativity on happy grammars
by j.romildo＠gmail.com 07 May '09

07 May '09

Hello. I am learning how to use Happy (a LALR(1) parser generator) and I have a question on a grammar based on an example from the manual. The input file to Happy is attached to this message. The grammar is: Exp -> let var = Exp in Exp Exp -> Exp + Exp Exp -> Exp - Exp Exp -> Exp * Exp Exp -> Exp / Exp Exp -> ( Exp ) This grammar is ambiguous, but the conflicts that will appear in the parser table can be resolved with precedence and associativity declarations for the operators that surround expressions: %right in %left + - %left * / giving right associativity to the in token, and left associativity to the arithmetic operators, and giving lower precedence to in, followed by + and -, and then by * and /. I see that if the token in is not given a precedence declaration, the grammar still is ambiguous, as can be seen in the example of parsing the expression: let v = e1 in e2 + e3 which could be parsed as (let v = e1 in e2) + e3 or let v = e1 in (e2 + e3) Giving the token in a lower precedence makes the parser choose the last option. My question is about the associativity of the token in? Does it make any difference giving it left associativity, right associativity, or making it non associative? Regards. José Romildo

1 0