August 2007 - Haskell-Cafe

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

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

13 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

monad subexpressions
by Chris Smith 13 Aug '07

13 Aug '07

I've heard Simon (Peyton-Jones) twice now mention the desire to be able to embed a monadic subexpression into a monad. That would be http://article.gmane.org/gmane.comp.lang.haskell.prime/2267 and in the recent OSCON video. Is someone working on implementing this? If no, I'll take a crack at it. If yes, I'd be slower than someone else, since I'm new to GHC. This seems like something a tad easier than type system extensions and the like since it's just desugaring... but a little harder than my "remove the GHCi banner" patch! In other words, a perfect step for me. Also, I got so frustrated that I ended up abandoning some code recently because STM is, in the end, so darn hard to use as a result of this issue. I'd love to see this solved, and I'm quite eager to do it. Proposals for syntax I've seen include: $( expr ) -- conflicts with template haskell ( <- expr ) -- makes sense, and I think it's unambiguous Other ideas: ``expr`` -- back-ticks make sense for UNIX shell scripters (| expr |) -- I don't think anything uses this yet Thoughts? -- Chris Smith

33 101

Re: [Haskell-cafe] out of core computing in haskell
by Carter T Schonwald 13 Aug '07

13 Aug '07

The main two use cases I have in mind are 1) really really really big abstract syntax trees or proof trees (a la compilers or theorem provers) 2) random access to numerical data does that help clarify what i'm asking about? In each case, is there a standard way of dealing with this? in the case of (1) the sensible way seems to me to do some sort of zipper representation which loads adjacent nodes to some depth surrounding your current location in the tree, and in the case of (2) it seems like the sensible way would be load subsequences of the data into memory. ----- Original Message ---- From: Andrew Coppin <andrewcoppin(a)btinternet.com> To: haskell-cafe(a)haskell.org Sent: Monday, August 13, 2007 3:55:57 PM Subject: Re: [Haskell-cafe] out of core computing in haskell Carter T Schonwald wrote: > Hello Everyone, > I'm not quite sure if I'm posing this question correctly, but what > facilities currently exist in haskell to nicely deal with > datastructures that won't fit within a given machine's ram? > And if there are no such facilities, what would it take to fix that? If you just want to process a big chunk of data from one end to the other without loading it all into RAM at once... that's fairly easy. Haskell is a lazy language. By playing with functions such as getContents, you can automatically load the data as you access it. No tricky programming required. If you're asking for something more specific -- e.g., "how do I talk to a standard database like Oracle / MySql / et al.", there are a couple of libraries for that. (Unfortunately, no one standard one.) See Stefan's answer. I'd you'd like to be more specific about what you'd like to do... _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Help with a project design
by Andrea Rossato 13 Aug '07

13 Aug '07

Hi, I'm going to be long, sorry for it. And probably also off topic, a bit at least...;-) I need a way to manage bibliographies, pretty common problem isn't it? I used to use a wiki I developed also for such a task.[1] The wiki was basically based on Bibtex. I thought I could rewrite that bibliographic management system in Haskell, but I've been also following the work of some guys who are trying to develop a style citation language in XML.[2] Since my confidence with Haskell is growing, I though I could try to write an implementation of that Citation Style Language, but now I start hitting my basic lack of computer science education. Such an effort would be useful if I could write a library and release it, which requires a clean architecture and a simple exported API. But, while I can grasp difficult computational concepts like monads or arrows, choosing a given path of development and create that API is probably out of my reach. This is why I'm asking for help. Or, probably better, for directions on how to start acquiring such capacities. The task this library should do is simple: given an xml object (representing a bibliographic reference), render it with rules stored in a different xml object (the citation style). While I think I can find solutions for this problem - the rendering -, what I find difficult is the design of the reference xml objects. Bibliographic entries have different types, which must be rendered differently. These types can be classified into 3 main classes (books, articles, parts of a book) that can be rendered with the same methods. That seems to fit Haskell perfectly. Now, I basically see 2 approaches: 1. create some data structures (most part of them is common) to map different types of bibliographic entries, and create the needed classes with the render methods; 2. keep the xml objects as xml and create an abstract interface to the xml objects to get the data required for rendering and classifying the xml objects. This way I would have to: - create data types to store different types of xml objects (data Book = Book XmlTree, data Artilce, etc.): these data types represent my reference classes; - create a class of 'render'-able types with the render method and define the instances; - create an existential type to set the type of the xml objects with some kind of setType :: XmlTree -> ExistentialContainer I think that the first approach is not abstract enough and requires a lot of boilerplate code to translate into a Haskell type a specific type of bibliographic entry. Moreover, this brings me back to Bibtex, that maps each entry type to a set of rendering rules, while xml objects (MODS[3]) have no type (type must be deduced by the presence of given elements). The second one is the one I'm leaning to. But I'm also thinking that probably I should first study a bit the "scrap your boilerplate" approach ... on the other side I think that I should probably take a path, follow it and see what happens. In other words, I keep on testing the feasibility of different approaches, probably because I did not grasp the problem entirely. And then there is the API, function names, argument disposition, and so on. Is there some material I could read to have some guidelines for such a task? I know that this is some kind of meta question that is not really Haskell specific, even though I would like to have Haskell specific answers...;-) But any kind of suggestion will be appreciated, especially if you can give me directions to materials that, even if not directly connected with my specific problem, can help me in understanding the basic principle of functional programming design. Thanks for your kind attention and sorry for such a long message. Andrea [1] http://uniwakka.sf.net [2] xbiblio.sf.net [3] "Metadata Object Description Schema" (MODS) http://www.loc.gov/standards/mods/

2 1

out of core computing in haskell
by Carter T Schonwald 13 Aug '07

13 Aug '07

Hello Everyone, I'm not quite sure if I'm posing this question correctly, but what facilities currently exist in haskell to nicely deal with datastructures that won't fit within a given machine's ram? And if there are no such facilities, what would it take to fix that? thanks -Carter

3 2

GHC optimisations
by Andrew Coppin 13 Aug '07

13 Aug '07

Does GHC do dead code elimination? I observe that if you take a module and edit it so that some function is now no longer exported or called by any exported function, the size of the *.o file seems to go down. This suggests that dead code within a single module is eliminated. However... how about this? module Foo where f = ... g = ... h = ... module Main where import Foo main = ...f... Will the generated executable contain the code for g and h, even though they aren't called? Or does the unused code get eliminated? How about the standard libraries? I read somewhere that if one funtion returns a tuple, and the caller immediately extracts the values from the tuple, GHC tries to optimise away the tuple - so it's as if the function can just return multiple values at once. Is this true? Does it apply only to tuples, or to all types?

2 4

zip3, zip4 ... -> zipn?
by Frank Buss 13 Aug '07

13 Aug '07

Is it possible to write a function like this: zipn n list_1 list_2 list_3 ... list_n which implements zip3 for n=3, zip4 for n=4 etc.? Looks like variable number of arguments are possible, like printf shows, so a general zipn should be possible, too. If it is possible, why there are functions like zip5 and not just zipn? -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de

12 13

xpath types for SYB/generic haskell type system?
by Alex Jacobson 13 Aug '07

13 Aug '07

The SYB papers provide really powerful functions for accessing and manipulating a values in arbitrary shaped containers. The cost of this capability appears to be loss of type checking. For example gfindtype x returns a maybe y. Given that the type checker actually has to know whether or not x actually contains a y inside of it, is there a way to annotate a gfindtype sort of function that just returns a value and if applied with the wrong type has a compiler enforce error? It may not be in this version of haskell, but it seems like there is no technical reason you could not have partial type annotations that describe the traversal strategies described in SYB. Perhaps it is a type version of an xpath expression e.g myFindType::(.//y) x => x->y The (.//y) x says that y is a type nested somewhere in x. Note, since this is happening at compiler time, this capability will still not prevent you from doing a (fromJust Nothing), but it still seems super valuable if you are doing generic haskell type stuff? Is there a mathematical reason why this wouldn't work? -Alex-

1 0