- Haskell-Cafe - Haskell.org

The usage of runghc ?
by keepbal 04 Feb '07

04 Feb '07

I tried to install haskell-fastcgi ( http://www.cs.chalmers.se/~bringert/darcs/haskell-fastcgi/ ). >runghc Setup.hs configure --prefix=$HOME/extra >runghc -I$HOME/extra/include Setup.hs build Preprocessing library fastcgi-2006.10.9... FastCGI.hsc:50:21: error: fcgiapp.h: No such file or directory compiling Network/FastCGI_hsc_make.c failed command was: ghc -c Network/FastCGI_hsc_make.c -o Network/FastCGI_hsc_make.o Setup.hs: got error code while preprocessing: Network.FastCGI >runghc --help runghc: syntax: runghc [-f GHCPATH] [GHC-ARGS] FILE ARG... ?

2 1

Proposal for allowing more use of layout to avoid parentheses and commas
by Brian Hulley 03 Feb '07

03 Feb '07

Hi, Following a recent thread on the Haskell' mailing list about the nusiance of having to deal with commas in tuples (when cutting and pasting things to re-order the elements there's always a pesky comma left over in the wrong place), I've written up a proposal for a very simple syntax tweak that would allow you to use the layout rule for function arguments, tuple/list/record contents etc for some future version of Haskell at http://www.haskell.org/haskellwiki/Accessible_layout_proposal This post is not intended to spark a lot of discussion just to point out the existence of the page for anyone interested. I've also added a link to all the new proposals from http://www.haskell.org/haskellwiki/Future . (If I don't reply to any follow up posts to this thread it's not because I'm ignoring them. It will just be because I have to try to get down to actually writing more of my program in the next few weeks, and I find thinking up ideas and reading posts, books, cooking, shopping, watching dvds etc, is infinitely more diverting than the painstakingly hard work of actual coding (though of course it's great in the rare occasions when things fall into place) ... ;-)) Brian. -- http://www.metamilk.com

1 0

(a -> [b]) vs. [a -> b]
by Chad Scherrer 03 Feb '07

03 Feb '07

Are (a -> [b]) and [a -> b] isomorphic? I'm trying to construct a function f :: (a -> [b]) -> [a -> b] that is the (at least one-sided) inverse of f' :: [a -> b] -> a -> [b] f' gs x = map ($ x) gs It seems like it should be obvious, but I haven't had any luck with it yet. Any help is greatly appreciated. Thanks, Chad

6 7

It matters how Type Synonyms are defined?
by Bryan Burgers 03 Feb '07

03 Feb '07

Today, I was plugging away on a program and I ran into a problem. It seems that ErrorT can or can not take a type synonym as its monad, depending on how the type synonym was defined. For example, consider this GHCi interactive run: > :k Maybe Maybe :: * -> * > let { a :: ErrorT String Maybe Bool; a = undefined } > :t a a :: ErrorT String Maybe Bool > :k State (Scope VVar) State (Scope VVar) :: * -> * > let { a :: ErrorT String (State (Scope VVar)) Bool; a = undefined } > :t a a :: ErrorT String (State (Scope VVar)) Bool ScopeState is defined in a file as: > type ScopeState a = State (Scope VVar) a > :k ScopeState ScopeState :: * -> * > let { a :: ErrorT String ScopeState Bool; a = undefined } <interactive>:1:6: Type synonym `ScopeState' should have 1 argument, but has been given 0 In the type signature: a :: ErrorT String ScopeState Bool Now, I was going to ask something like, "How can I define my type synonym so I can do this," but I figured out while writing this email that if I define ScopeState a different way: > type ScopeState = State (Scope VVar) > :k ScopeState ScopeState :: * -> * > let { a :: ErrorT String ScopeState Bool; a = undefined } > :t a a :: ErrorT String ScopeState Bool So, my new question is: Why does it matter how ScopeState is defined? Bryan Burgers

4 3

Levels of recursion
by Andrew Wagner 02 Feb '07

02 Feb '07

I won't speak for anyone else, but I remember when recursion first "clicked". It was in a 400-level data structures and algorithms class. I had already done a fair amount of chess programming (which of course does a massive amount of recursion), but it still seemed a bit magical to me. When the professor pointed out that you simply have to assume that the recursive call will work, and then the whole recursive definition will, a light bulb went on. Of course, once I started learning haskell, such "aha!" moments quickly became a way of life. Things like map, foldr, and the lazy definition of fibs all made me stop and think for a while, and when I understood them, I was better for it. I had a sort of interesting moment like this last night. In hacking on some code, I wrote the following function: combine :: [Int] -> [Int] -> [[Int]] combine [] _ = [] combine (x:xs) ys = (take x ys) : (combine xs (drop x ys)) To me, this is recursion. Define your base case, take care of one part of the problem, and then call yourself recursively to take care of the rest. This is how I was taught recursion, and this is how I think about it. Now for the fun part. A much more experienced haskeller told me he preferred to write it like this: combine' :: [Int] -> [Int] -> [[Int]] combine' xs ys = snd $ mapAccumL aux ys xs where aux ys n = (b,a) where (a,b) = splitAt n ys Ack! Where'd the nice "base-case, take a chunk, recursively do the rest" pattern go? Suddenly, recursion isn't so simple when it's done using composition and higher-order functions which abstract recursive patterns. Like I said, I'm familiar with map, foldr, etc. But this is the first time it's dawned on me that I need to think in more general recursive patterns like this instead of simple, raw recursion. That map and foldr aren't JUST a nice way of doing things to a little list, but they are recursive operators, building blocks that I need to use as fluently as anything else. I suspect I'm not alone, though of course I could be wrong. But I would bet that a significant difference between newbies and more experienced Haskell programmers is the degree to which they can think in this composition/HOF way. Where the beginner wants to program using raw, simple recursion, the more experienced sees an opportunity to apply an abstraction. So, a couple of questions to ponder about this: Is this unique to Haskell, or could the same be said about any functional language? How can we teach this better to newbies? Most of what I see in the tutorials is "Higher order functions accept as parameters and/or return other functions. Here's some examples: <explanation of map>, <explanation of foldr>. Moving on, ..." But clearly, this is something important, and I think we can do a better job of teaching it. Suggestions?

4 3

"Write Yourself a Scheme in 48 Hours"
by Shannon -jj Behrens 02 Feb '07

02 Feb '07

I'm going through the "Write Yourself a Scheme in 48 Hours" <http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/overview.html> tutorial. I like it a lot, but I have some concerns. Are the exercises in the tutorial known to be solvable by mere mortals? For instance: "Rewrite parseNumber using...explicit sequencing with the >>= operator" http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/parser.html#s… There aren't any examples of using >>= previous to this question. Furthermore, the link to the Standard Prelude is not helpful because there aren't any examples of how to use >>=. Furthermore, consider the exercise: "Change parseNumber to support the Scheme standard for different bases. You may find the readOct and readHex functions useful." http://halogen.note.amherst.edu/~jdtang/scheme_in_48/tutorial/parser.html#s… I struggled against this for a couple hours last night. How is the reader supposed to figure out readOct, which is part of ReadS, without understanding the whole ReadS business? If the reader does understand the ReadS business, he probably already understands Haskell far better than the tutorial seems to suggest. I eventually figured out how to write: parseHexNumber = do char '#' char 'x' s <- many1 (oneOf "0123456789abcdefABCDEF") case readHex s of [(n,"")] -> return n but it was no small feat. Furthermore, it was only possible because I had already spent so much time trying to understand "A Gentle Introduction to Haskell". Worst of all, once I had it all implemented, the parser *from* the tutorial: parseExpr :: Parser LispVal parseExpr = parseAtom <|> parseString <|> parseNumber led to some surprising results. It turns out that "#o9", which should be an invalid attempt at an octal number, is getting parsed as an atom. There's a whole layer of difficulty that seems insurmountable by mere mortals like me using just this tutorial and minimal reference usage. What am I missing? Is it really solvable by mere mortals who don't already know Haskell, the Parsec module, etc.? Thanks, -jj -- http://jjinux.blogspot.com/

3 3

Become a GHC build slave!
by Simon Marlow 02 Feb '07

02 Feb '07

Thanks largely to Ian Lynagh, GHC now has a BuildBot infrastructure to automate nightly builds on multiple platforms. This replaces the old set of shell scripts that we used to run nightly builds; now adding new clients to the setup is relatively easy, instructions are here: http://hackage.haskell.org/trac/ghc/wiki/BuildBot So far we have various Windows builds running, and I'll be moving over the existing Linux nightly builds in due course. If you have a spare machine or a machine that is idle overnight, and you'd like to use it to run automated GHC builds, then please take a look at the above page for how to get started. We especially need platforms that we don't use regularly (i.e. not Windows or Linux/x86/x86_64). Cheers, Simon

2 1

A distributed and replicating native Haskell database
by Joel Reymont 02 Feb '07

02 Feb '07

Folks, Allegro Common Lisp has AllegroCache [1], a database built on B-Trees that lets one store Lisp objects of any type. You can designate certain slots (object fields) as key and use them for lookup. ACL used to come bundled with the ObjectStore OODBMS for the same purpose but then adopted a native solution. AllegroCache is not distributed or replicating but supports automatic versioning. You can redefine a class and new code will store more (or less) data in the database while code that uses the old schema will merrily chug along. Erlang [2] has Mnesia [3] which lets you store any Erlang term ("object"). It stores records (tuples, actually) and you can also designate key fields and use them for lookup. I haven't looked into this deeply but Mnesia is built on top of DETS (Disk-based Term Storage) which most likely also uses a form of B-Trees. Mnesia is distributed and replicated in real-time. There's no automatic versioning with Mnesia but user code can be run to read old records and write new ones. Would it make sense to build a similar type of a database for Haskell? I can immediately see how versioning would be much harder as Haskell is statically typed. I would love to extend recent gains in binary serialization, though, to add indexing of records based on a designated key, distribution and real-time replication. What do you think? To stimulate discussion I would like to ask a couple of pointed questions: - How would you "designate" a key for a Haskell data structure? - Is the concept of a schema applicable to Haskell? Thanks, Joel [1] http://franz.com/products/allegrocache/index.lhtml [2] http://erlang.org/faq/t1.html [3] http://erlang.org/faq/x1409.html -- http://wagerlabs.com/

3 3

Boost equivalent
by John Ky 02 Feb '07

02 Feb '07

Hi, Does the Haskell community have an equivalent to C++ community's Boost project with the aim of writing libraries for the eventual inclusion into Haskell? Thanks -John

9 8

Array copy performance
by Chris Kuklewicz 02 Feb '07

02 Feb '07

Hi, I am trying to improve the memory usage of regex-tdfa and I wanted to ask an array question. If I have two identical STUArrays (same type and bounds) then what is the most efficient way to overwrite the data in the destination with the data in the source? Does this work for STArrays? Is there a GHC only solution? Is there a way to avoid the long loop? > forM_ (range b) $ \index -> > readArray source index >>= writeArray destination index Is Data.Array.Storable the only route? I do not think Data.Array.Diff will work well since I have one source going to multiple destinations, each with a few different changes. -- Chris

3 2