- Haskell-Cafe - Haskell.org

haskell and webapplications + a WASH and a WebFunction question
by Marc Weber 13 Mar '07

13 Mar '07

Hello, I've noticed that the summer of code tickets contain one item: "lightweight web framework". I've dropped out university one year ago. So I can't participate, right? Do you want to explore with me how this might be done propably using HAppS or fastcgi ? I just need another person to talk to to. (mailinglist will do as well ;) I think webfunction is a very good starting point. Would it be worth adding a page like haskellIDE http://haskell.org/haskellwiki/HIDE to collect ideas ? There are still some question I could not answer yet eg: WASH: How is askContinuously used? did anyone use WASH with FastCGI ? I've tried looking at the apis. FastCGI (mantained by Bringert) seems to need the HTTP response as plain text (either ByteString or lazy String) whereas WASH wants to write to a handle (see function start wehere initEnv stdin stdout) is called and sets cgiHandle which seems to be the handle to be written to. Did I get this right? Is there an easier way then rewriting WASH? WebFunctions: When using dog http:localhost:8080.. dog prints the html page and waits still 10s because the WebFunction webserver waits for another request. This is caused by b <- myHWaitForInput h 10 in file LLWebServer.hs which makes it impossible to use benchmarking tools such as ab2 from apache. Do you know wether this is bug? Marc

1 0

Re: Type and State Confusion
by Hans van Thiel 13 Mar '07

13 Mar '07

Albert, Thanks very much for your explanation. I see now that I confused the state function with the f, but it's still not quite clear. data MyState a b = MyStateC ([a] -> ([a], b)) This defines an algebraic data type (...why is it called algebraic?) with two type variables and a unary constructor. instance Monad (MyState a) where return x = MyStateC (\tb -> (tb, x)) (MyStateC st) >>= f = MyStateC (\tb -> let (newtb, y) = st tb (MyStateC trans) = f y in trans newtb ) Now, if the instantiated a has type String, Int or whatever, I would understand, but the type of the Monad seems to be built up from two types. You write: ...y has type String. In more detail: in order for foo >>= toMyState to make sense, these must be the types: foo :: MyState String String st :: [String] -> ([String], String) y is forced to have type String for the sake of toMyState. But how do the two occurrences of String in the foo type, in general a and b, match to the single a in the instance declaration? In particular when I have: toMyState :: String -> MyState String Int toMyState x = MyStateC (f x) This is mapped onto a list of strings, on which the Prelude sequence is applied. sequence :: Monad m => [m a] -> m [a] You write: The >>= used by sequence is the same >>= in the MyState monad, since you instantiate m to MyState String. Therefore, sequence performs all the state transformations correctly, since >>= is correct. So the m becomes MyState String, and therefore the list elements have type (MyState String Int), or the other way around. I understand, from your explanation, how this works from there on, but I'm still confused about what the Monad is. Is it MyState which takes two types, or (MyState String) which takes one type? Or neither? Does it involve some 'sort of currying' of type parameters? Thanks again, Hans

2 2

GHC optimization changes evaluation strategy?
by Dusan Kolar 13 Mar '07

13 Mar '07

Hello all, the following program changes behavior if translated using different options for ghc compiler. Is this correct or not? I used The Glorious Glasgow Haskell Compilation System, version 6.6. And I would expect in both cases behavior 1. But I may be wrong... Thanks for any resolution. Dusan *Program:* $ cat Test.hs import System.IO.Unsafe import System.IO main = do putStr "Start...\n" putStr $ show $ falling' falling10000 putStr "\n" putStr $ show $ sorted' rising10000 putStr "Stop...\n" sorted' [] = True sorted' [_] = True sorted' l = sx l 1 where sx [] _ = True sx [_] _ = True sx (x:l@(y:ys)) n = if n==1000 then unsafePerformIO (putChar '.' >> hFlush stdout) `seq` x<=y && sx l 1 else x<=y && (sx l $! n+1) falling' [] = True falling' [_] = True falling' l = sx l 1 where sx [] _ = True sx [_] _ = True sx (x:l@(y:ys)) n = if n==1000 then unsafePerformIO (putChar '.' >> hFlush stdout) `seq` x>=y && sx l 1 else x>=y && (sx l $! n+1) rising10000 = [0..100000] falling10000 = [100000,99999..0] -- EOF *Behavior 1:* $ ghc Test.hs -o test $ ./test Start... ....................................................................................................True ....................................................................................................TrueStop... *Behavior 2:* $ rm test Test.o Test.hi $ ghc -O2 Test.hs -o test $ ./test Start... .True .TrueStop... -- Dusan Kolar tel: +420 54 114 1238 UIFS FIT VUT Brno fax: +420 54 114 1270 Bozetechova 2 e-mail: kolar(a)fit.vutbr.cz Brno 612 66 Czech Republic --

2 1

Ann: regex-base-0.91
by Chris Kuklewicz 13 Mar '07

13 Mar '07

I have updated the darcs repository and the hackage repository to have regex-base-0.91 Changes: GHC uses late instance overlap detection, whereas Hugs demands no potential overlap. Thus Hugs rejected some of the polymorphic results for matching given by RegexContext instances. The solution in version 0.91 of regex-base is to use newtypes. To this end there are 4 newtypes which are used to disambiguate some of the more complicated return types of match/matchM/=~/=~~. The new haddock documentation for Text.Regex.Base.Context has more details and lists all the instances. The 4 newtypes are: > newtype AllSubmatches f b = AllSubmatches {getAllSubmatches :: (f b)} > newtype AllTextSubmatches f b = AllTextSubmatches {getAllTextSubmatches :: (f b)} > newtype AllMatches f b = AllMatches {getAllMatches :: (f b)} > newtype AllTextMatches f b = AllTextMatches {getAllTextMatches :: (f b) } The 'f' parameters are containers types, such as [] or (Array Int). The two *Submatches types report all the captured (i.e. parenthesized) groups of the first match found. The two *Matches types report on the all the non-overlapping matches found. This clarifies the desires of the programmer and allows choice of either result to be made. The two *Text* version have the type of the searched text included in the type of the result 'b', unlike the other two types. This avoids overlapping. These newtypes are not used for all the instances, but only where they are needed to either avoid overlapping or remove possible confusion. Using this newtype schema has allowed a few new instances to be added. In particular all the instances should have a [] or (Array Int) option for the returned container. -- Chris Kuklewicz

1 0

idea for avoiding temporaries
by David Roundy 13 Mar '07

13 Mar '07

Hi all, I was just teaching a class on minimization methods, with a focus on conjugate gradient minimization in particular, and one of my main points was that with conjugate gradient minimization we only need three or four arrays of size N (depending on whether we use the Fletcher-Reeves or Polak-Ribiere variant), that this was a huge win, and I was explaining that in my code we use Fletcher-Reeves even though it's generally got less stable convergence behavior, because avoiding one extra copy is well worth it, when each copy is on the order of a gigabyte (which is not unusual in my line of work). This got me thinking about one of the largest problems with writing serious numerical code in Haskell, which is that of memory consumption and avoiding temporary variables. The count of three arrays requires assumes that we do in-place updates, which presupposes an imperative model. But the main reason I'd like to switch to Haskell is so that I can write pure functional code, which is easier to read, easier to reason with, and easier to get right. So I started wondering whether there's a solution that would allow us to write pretty high-level pure functional code, while the RTS can realize at run-time that we have the only reference to the input argument and that it is therefore safe to consume it destructively. My thought is to move some of the amazing rewriting streams stuff that's going on with Data.ByteStream and Manuel's array fusion work onto the memory management level. If we can rewrite high-level array manipulations into a form in which the compiler can fuse the loops and write good low-level code, why not also allow automatic in-place updates (when possible)? My thought is to create a function like the following: copy :: ForeignPtr a -> IO (ForeignPtr a) This function ordinarily copies its input into a new chunk of memory, and then calls the initialization function to update that memory. So we could call it with something like a `plus` b = do a' <- copy a a' `plusEqual` b return a' Of course, in practice I imagine this whole business being encapsulated in a module where it's called with unsafePerformIO (but it's really perfectly safe, a la Data.ByteString). The key is that copy will ask the GC to check whether there is more than one reference to its input, and if there isn't, then it'll return its input without making a copy. Obviously, we'd want to be careful in making calls to copy (since the GC overhead could overwhelm the potential (transient) memory savings. And I've got no idea how hard it would be to find out if there are no other references, or how effective this would be... that is, whether the compiler might generate "false" references to the input that would prevent the savings from ever being realized. There are also other questions. My copy above is simple, but probably we'd be better off with a more general: copy :: a -> (a -> IO a) -> IO a which could be used in the base libraries for other sorts of objects, such as Array, which might not have a ForeignPtr at their back end. We might also want a more general copy that would handle the case where we would like to copy either one variable or another, and we don't care which. i.e. we in my `plus` example above, if "a" can't be discarded, but "b" can, we'll be out of luck. Perhaps we want something like reuseOrNot :: a -> (a -> IO b) -> (a -> IO b) -> IO b which would call one function or the other, depending on whether the input is deemed expendible by the GC, so we could write a `plus` b = reuseOrNot a (\a' -> do { a' `plusEqual` b; return a' }) (\a' -> reuseOrNot b (\b' -> do { b' `plusEqual` a'; return b' }) (\b' -> a' `boringAdd` b')) where boringAdd is an addition that doesn't reuse either array. Anyhow, all this would be predicated on the possibility of asking the GC whether anyone else has a reference to a given object, and I've no idea how tough (or slow) this would be. It'd also be effectively predicated on someone like dons having the time and interest to write good fusion code which would allow one to make use of this in referentially transparent high-level pure functional code. I think it'd be pretty cool, and would certainly (not immediately, but as my research group ramps up) be interested in being a guinea pig user of this stuff. Any thoughts? Am I crazy? Is this infeasible for some reason? Should I have patented this idea before mentioning it on the list? Has someone else already patented it? -- David Roundy Department of Physics Oregon State University

18 50

Random/StdGen/read: there is something unclear (or misunderstood!)
by Zara 13 Mar '07

13 Mar '07

Sorry if this question is too basic, but I am trying to learn Haskell and from tiem to time I get stuck. (And forgive me, I haev a heavy procedural background, so functional programming is hard for me) I am trying to use 'read' to create a random generator, applying it on some text. As the Report, says: # In addition, 'read' may be used to map an arbitrary string (not # necessarily one produced by 'show') onto a value of type 'StdGen'. # In general, the 'read' instance of 'StdGen' has the following # properties: # # * It guarantees to succeed on any string. # # * It guarantees to consume only a finite portion of the string. # # * Different argument strings are likely to result in different # results. But it does not succeed on "any string". Code follows \begin{code} module Pepe where import Random pepin :: StdGen pepin = read "cosita" pepe :: StdGen pepe = read "cositaLinda" \end{code} If I evaluate pepin, results are: Hugs> pepin 38273 1 :: StdGen (360 reductions, 554 cells) But if I evaluate pepe, all changes: Hugs> pepe Program error: Prelude.read: no parse (380 reductions, 694 cells) Am I misunderstanding something, or is StdGen -> read buggy? As you can see, I am using Hugs, version Sep 2006 to test. TIA, best regards, Zara

2 1

Church Encoding Function
by Joachim Breitner 12 Mar '07

12 Mar '07

Hi, some more ideas following from the last post. I noticed how the function Data.Maybe.maybe converts a Haskell Maybe into a Church encoded Maybe. Also, the if construct, interpreted as a function, converts a Bool into a church encoded Bool. If lists are encoded as forall b. (a -> b -> b) -> b -> b, then foldr, with the right order of arguments, converts a haskell [] to a Church encoded List. Is there a name for these functions? “Characteristic Church Encoding Functions” maybe? Are there more than these: Maybe -- maybe Bool -- ifthenelse List -- foldr (,) -- uncurry Just a short idea while waiting at the airport... Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: joachimbreitner(a)amessage.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

9 9

Haskell for Accessibility
by Tom Hawkins 12 Mar '07

12 Mar '07

I love programming in Haskell, yet even its concise expressions have not saved my tendons from chronic RSI. Has anyone put any thought into building an accessible Haskell development interface for those who may not be able to use a keyboard? One inspirational program is Dasher (http://www.inference.phy.cam.ac.uk/dasher/) Not only is it godsend for people with a wide range of disabilities, Dasher is also a lot of fun to use. Though Dasher is good at general text entry, it's not well suited for programming. However, combining Dasher's statistical inference with Haskell's type inference might yield a graphical, cursor driven interface even more efficient than the conventional keyboard. Is there interested in such a project? I don't have the expertise or typing strength (pun intended) to go it alone, but I could lend a hand. Here are a few random ideas: - A tree viewer to navigate and manage directories, modules, module declarations, and expressions. Similar to a directory explorer, nodes in the tree can be collapsed and expanded. Collapsed module definitions would display the type annotation, while hiding the definition. - Another interface for composing expressions. This interface could be similar to Dasher, but use both statistical inference and type inference to weight and prune the decision tree. The expression composer interface could directly assemble the abstract syntax tree, thus eliminating the need for whitespace and ()s. Of course, the tree viewer would pretty print all expressions in the familiar Haskell layout. - The development environment could be hosted as a web server, delivering SVG and minimal JavaScript for the client-side interface, allowing Haskell program development from any web browser with a 2 button mouse -- head mounted or eye tracked, of course. The client-server architecture would allow developers to concurrently work from the same source code. - >From the tree viewer, click any expression to view the compiler's inferred type, with the ability to turn any inferred type into a concrete type annotation. And the ability to compare inferred types to type annotations. Type violations highlighted in red. - Variable references would not have to be explicitly spelled out. Instead, variables could be selected from either the tree viewer or expression composer, forming a hard link. When a variable's name changes, all references could be automatically updated. When an expression is either moved or copied into a new lexical scope, the variable references could be automatically rebound to variable definitions in the new scope. Unmatched referenced names and ambiguous names would be highlighted in red. -Tom

3 2

CFP: Prog. Lang for Mechanized Mathematics Workshop
by Jacques Carette 12 Mar '07

12 Mar '07

Programming Languages for Mechanized Mathematics Workshop As part of Calculemus 2007 <http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/> Hagenberg, Austria [http://www.cas.mcmaster.ca/plmms07/] The intent of this workshop is to examine more closely the intersection between programming languages and mechanized mathematics systems (MMS). By MMS, we understand computer algebra systems (CAS), [automated] theorem provers (TP/ATP), all heading towards the development of fully unified systems (the MMS), sometimes also called universal mathematical assistant systems (MAS) (see Calculemus 2007 <http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/>). There are various ways in which these two subjects of /programming languages/ and /systems for mathematics/ meet: * Many systems for mathematics contain a dedicated programming language. For instance, most computer algebra systems contain a dedicated language (and are frequently built in that same language); some proof assistants (like the Ltac language for Coq) also have an embedded programming language. Note that in many instances this language captures only algorithmic content, and /declarative/ or /representational/ issues are avoided. * The /mathematical languages/ of many systems for mathematics are very close to a functional programming language. For instance the language of ACL2 is just Lisp, and the language of Coq is very close to Haskell. But even the mathematical language of the HOL system can be used as a functional programming language that is very close to ML and Haskell. On the other hand, these languages also contain very rich specification capabilities, which are rarely available in most computation-oriented programming languages. And even then, many specification languages ((B, Z, Maude, OBJ3, CASL, etc) can still teach MMSes a trick or two regarding representational power. * Conversely, functional programming languages have been getting "more mathematical" all the time. For instance, they seem to have discovered the value of dependent types rather recently. But they are still not quite ready to 'host' mathematics (the non-success of docon <http://www.haskell.org/docon/> being typical). There are some promising languages on the horizon (Epigram <http://www.e-pig.org/>, Omega <http://web.cecs.pdx.edu/%7Esheard/Omega/index.html>) as well as some hybrid systems (Agda <http://agda.sourceforge.net/>, Focal <http://focal.inria.fr/site/index.php>), although it is unclear if they are truly capable of expressing the full range of ideas present in mathematics. * Systems for mathematics are used to prove programs correct. (One method is to generate "correctness conditions" from a program that has been annotated in the style of Hoare logic and then prove those conditions in a proof assistant.) An interesting question is what improvements are needed for this both on the side of the mathematical systems and on the side of the programming languages. We are interested in all these issues. We hope that a certain synergy will develop between those issues by having them explored in parallel. These issues have a very colourful history. Many programming language innovations first appeared in either CASes or Proof Assistants, before migrating towards more mainstream languages. One can cite (in no particular order) type inference, dependent types, generics, term-rewriting, first-class types, first-class expressions, first-class modules, code extraction, and so on. However, a number of these innovations were never aggressively pursued by system builders, letting them instead be developped (slowly) by programming language researchers. Some, like type inference and generics have flourished. Others, like first-class types and first-class expressions, are not seemingly being researched by anyone. We want to critically examine what has worked, and what has not. Why are all the current ``popular'' computer algebra systems untyped? Why are the (strongly typed) proof assistants so much harder to use than a typical CAS? But also look at question like what forms of polymorphism exists in mathematics? What forms of dependent types exist in mathematics? How can MMS regain the upper hand on issues of 'genericity'? What are the biggest barriers to using a more mainstream language as a host language for a CAS or an ATP? This workshop will accept two kinds of submissions: full research papers as well as position papers. Research papers should be nore more than 15 pages in length, and positions papers no more than 3 pages. Submission will be through _EasyChair_. An informal version of the proceedings will be available at the workshop, with a more formal version to appear later. We are looking into having the best papers completed into full papers and published as a special issue of a Journal (details to follow). Important Dates April 25, 2007: Submission Deadline June 29-30, 2007: Workshop Program Committee Lennart Augustsson <http://www.cs.chalmers.se/%7Eaugustss> [Credit Suisse] Wieb Bosma <http://www.math.ru.nl/%7Ebosma/>[Radboud University Nijmegen, Netherlands] Jacques Carette <http://www.cas.mcmaster.ca/%7Ecarette> (co-Chair) [McMaster University, Canada] David Delahaye <http://cedric.cnam.fr/%7Edelahaye/> [CNAM, France] Jean-Christophe Filliâtre <http://www.lri.fr/%7Efilliatr/> [CNRS and Université de Paris-Sud, France] John Harrison <http://www.cl.cam.ac.uk/%7Ejrh13/> [Intel Corporation, USA] Markus (Makarius) Wenzel <http://www4.in.tum.de/%7Ewenzelm/> [Technische Universität München, Germany] Freek Wiedijk <http://www.cs.ru.nl/%7Efreek/> (co-Chair) [Radboud University Nijmegen, Netherlands] Wolfgang Windsteiger <http://www.risc.uni-linz.ac.at/people/wwindste/> [University of Linz, Austria] Location and Registration Location and registration information can be found on the Calculemus <http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007/> web site.

1 0

A valuable new combinator for Parsec?
by Maxime Henrion 12 Mar '07

12 Mar '07

Hello all, While using the very nice "option" combinator of Parsec recently, it seemed to me that it would be useful to have a more specific kind of combinator for optional tokens that wraps the token into a Maybe type. So, that gives: pmaybe :: GenParser tok st a -> GenParser tok st (Maybe a) pmaybe p = option Nothing (p >>= return . Just) I've been using it happily with some code of mine. Do people think that it would be generally useful to have in Parsec? Cheers, Maxime

3 2