- Haskell-Cafe - Haskell.org

Question about Haskell types
by Pete Chown 26 Feb '06

26 Feb '06

I've been trying to get to the point with Haskell where I can write useful programs, and I've come across something I don't understand with the type system. I hope this is the right place to ask. I came up with the following list of declarations: a = (<) b x = (x <) c x y = (x < y) It turns out that 'a' is badly typed and gives an error at compile time. 'B' and 'c' are equivalent and have type "Ord a => a -> a -> Bool". What I don't understand is why 'a' doesn't behave the same way as the other two. Thanks for any help you can give me, and in the meantime I'll go back to relearning everything I thought I knew about programming. :-) Pete

3 2

Monads (was "how to write an interactive program ? gui library to use ?")
by Jared Updike 25 Feb '06

25 Feb '06

(Note, moved to haskell-cafe.) > Essentially, the answer is "yes", the state needs to be passed around > (neglecting hackery to simulate global variables that is better > avoided). However, this can be made convenient by using a monad. BTW, Minh, If you don't know what monads are, then read this. Monads are an indispensable part of programming in Haskell: http://www.nomaware.com/monads/html/ http://haskell.org/hawiki/Monad Monads are good. Monads are your friend. Jared. -- http://www.updike.org/~jared/ reverse ")-:"

1 0

Context in data and class declarations (was haskell programming guidelines)
by Brian Hulley 25 Feb '06

25 Feb '06

Hi - In http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/het… one of the recommendations states: "Don't put class constraints on a data type, constraints belong only to the functions that manipulate the data." This made me think: what on earth was the point of allowing contexts on a data declaration in the first place? I've always found it a confusing feature of Haskell since you in any case need to "repeat" all the (relevant) constraints when declaring the type of any function that manipulates the data. There does not appear to be any sensible reason for requiring the constraints for constructor functions, because the constructor functions would never ever need to use them... Therefore would it be a good idea to get rid of this feature altogether? Another confusing thing is the use of the word "inheritance" in tutorials/books about class declarations. Unlike object oriented languages, where a class or interface gets all the methods of its ancestor classes/interfaces in addition to some new methods declared at that level, each Haskell type class is completely independent of any other type class. For example, the class Ord contains methods for (<) (<=) (>=) (>) max min but does not contain the methods of Eq even though this confusing word "inheritance" or "superclass" would imply that it should. Ord does *not* "inherit" anything at all - the meaning of the Eq context in the class declaration is just that we will need the Eq dictionary in addition to the Ord dictionary when calling any of Ord's methods. Thus I propose that the contexts don't really have any place in a class declaration either ie class Eq a => Ord a where (<), (<=), ... :: would be better written as: class Ord a where (<), (<=), .... :: Eq a => a->a->Bool so the language wouldn't be so confusing to learn. Classes are after all extremely simple! :-) Regards, Brian.

1 1

graphics on mac os x
by jeff p 24 Feb '06

24 Feb '06

Hello, I am running ghc 6.4.1 on mac os X (10.4.5). Can anyone give me some pointers for getting graphics functionality? I have tried wxhaskell, but it gives me the error HelloWorld.hs:4:0: Failed to load interface for `Graphics.UI.WX': Bad interface file: /usr/local/wxhaskell/lib/imports/Graphics/UI/WX.hi mismatched interface file versions: expected 6041, found 6040 when I try to compile the HelloWorld.hs program following the mac os x instructions. I have also tried to run Graphics.HGL in X11, but I get the error: Loading package X11-1.1 ... can't load .so/.DLL for: X11 (dlopen(libX11.dylib, 10): image not found) when I try to run the obligatory "Hello World" program from inside ghci. Are there other high/medium level graphics options for haskell on macs? Any help would be appreciated. thanks, Jeff

2 1

Best representation of graph for use in a zipper?
by Daniel McAllansmith 24 Feb '06

24 Feb '06

Hi I've been having a look at zippers over homogenous tree data types, and was wondering how best to represent a heterogeneous graph for manipulation with a zipper. The main example of zippers I've been looking at is http://okmij.org/ftp/Computation/Continuations.html#zipper-fs and http://okmij.org/ftp/Computation/Continuations.html#zipper from which I've included a small extract at the end of this email to provide extra context if necessary. For contrived example, given a relational model: .Album . |1 . | . | . |1..n 0..n 1 .Performance--------Song . |0..n |1 . | | . | |0..n . |1 WritingCredit . Performer |0..n . ^ ^ | . | |------ | . | | | . | 1 1..n | |1 .Group--------Artist I could write a data type: > data MC > = Album {perfs ::[MC]} > | Performance {album :: MC, song :: MC, performer :: MC} > | Song {perfs :: [MC], artistCredits :: [MC]} > | Group {perfs ::[MC], artists :: [MC]} > | Artist {perfs :: [MC], songCredits :: [MC]} > | Root {albums :: [MC]} The first problem I have with this is that it doesn't enforce enough structural constraints. Secondly, as I understand it, whilst zippers can handle cyclic structures they do so by doing a 'copy-on-write'. I would like to maintain shared instances. I could flatten the data type graph to a minimal spanning tree: > data MCFK = MCFK > data MC > = Album {fKey :: MCFK, perfs ::[MC]} > | Performance {fKey :: MCFK, songFK :: MCFK, performer :: MCFK} > | Song {fKey :: MCFK, artistCredits :: [MCFK]} > | Group {fKey :: MCFK, artists :: [MC]} > | Artist {fKey :: MCFK} > | Root {albums :: [MC], songs :: [MC], groups :: [MC], soloArtists :: [MC]} This seems a bit better. The traversal function doesn't have to worry about cycles and there's less mainenance updates to do. But it still doesn't offer any structural or foreign key guarantees. I thought that I would be able to use a GADT to give structural guarantees, though not FK guarantees, but once I move to a GADT I don't know how to write a traversal function as the next node could be of several different types. Any advice on how to get a safer data structure, and write the necessary traversal function, would be much appreciated. Cheers Daniel Following is an extract from the links above. Note that I have floated the functions local to traverse up to the top level to get at them with GHCi > data Term = Var String | A Term Term | L String Term deriving (Show) > > data Direction = Down | DownRight | Up | Next deriving (Eq, Show) > > traverse :: (Monad m) => (Direction -> Term -> m (Maybe Term, Direction)) -> Term -> m Term > traverse tf term = traverse' tf id Down term >>= maybeM term id > > > traverse' tf next_dir init_dir term = do > (term', direction) <- tf init_dir term > let new_term = maybe term id term' > select tf (next_dir direction) new_term >>= maybeM term' Just > > next next_dir dir = if dir == Next then next_dir else dir > > maybeM onn onj v = return $ maybe onn onj v > > select tf Up t = return Nothing > select tf Next t@(Var _) = return Nothing > select tf dir t@(L v t1) | dir == Next || dir == Down = do > t' <- traverse' tf id Down t1 >>= (return . fmap (L v)) > traverse' tf (next Up) Up (maybe t id t') >>= maybeM t' Just > select tf DownRight t@(A t1 t2) = do > t' <- traverse' tf id DownRight t2 >>= > (return . fmap (\t2'->(A t1 t2'))) > traverse' tf (next Up) Up (maybe t id t') >>= maybeM t' Just > select tf dir t@(A t1 t2) | dir == Next || dir == Down = do > t' <- traverse' tf id Down t1 >>= > (return . fmap (\t1'->(A t1' t2))) > traverse' tf (next DownRight) Up (maybe t id t') >>= > maybeM t' Just > > > --Testing > trav dir term = do print dir; print term; return (Nothing,Next) > > > term1 = A (Var "v1") (L "l1" (A (Var "v2") (Var "v3"))) > > test1 = traverse trav term1

1 0

RE: [Haskell-cafe] Re: Hashtable woes
by Simon Marlow 23 Feb '06

23 Feb '06

On 21 February 2006 17:21, Chris Kuklewicz wrote: > From the shooutout itself: > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lan g=ghc&id=3 > > and > > http://shootout.alioth.debian.org/gp4/benchmark.php?test=knucleotide&lan g=ghc&id=2 > > (I forget the exact different between them) > > From the wiki (the Current Entry): > > http://haskell.org/hawiki/KnucleotideEntry#head-dfcdad61d34153143175bb9f 8237d87fe0813092 Thanks... sorry for being a bit dim, but how do I make this test run for longer? I downloaded the example input. The prog doesn't seem to take an argument, although the shootout suggests it should be given a parameter of 250000. Cheers, Simon

3 2

Re: [Haskell] page renaming on the Haskell Wiki
by Graham Klyne 22 Feb '06

22 Feb '06

Wolfgang, [Switching to haskell-cafe] Re: [1] http://www.mail-archive.com/haskell@haskell.org/msg18352.html [2] http://www.mail-archive.com/haskell@haskell.org/msg18356.html [3] http://www.w3.org/Provider/Style/URI Wolfgang Jeltsch wrote (in [2]): > On the other hand, I think that the above W3C article is far too extreme. It > tells you that stability is the most important thing concerning URIs. I will pursue this a little further, because I think that getting the web presence right is very important to maintaining an online community. It may be that we must agree to disagree, but based on my experience of using the web, stability of URIs *is* the most important thing (after content, of course). I have been using the W3C web site now for many years, and the inconsistencies you mention have never been a problem for me -- indeed, I hadn't even noticed them until you mentioned them. Why is this? I hypothesize that it is because, when the Web is used effectively, it is really quite rare to enter a URI manually. Instead, one uses various index pages, RSS feeds, search tools and so on to find a URI, and then simply click on it. Many URIs are never seen by human eye, but placed behind descriptive links. W3C themselves use URIs very intensively in transient communications, and their mailing system is set up to facilitate this (see their x-archived-at mail headers). A result of this is that the email archives, together with the web site pages, form a tightly interlinked collection of documents and comments that can be, and are, frequently cross-referenced rather than reinvented. But, for this to work, once a link has been placed in a document, feed, archive or whatever, it is crucially important that it continues to work for as long as the information it references is of interest to people. Without this, all the devices we use to find our way around the web simply fail -- not all at once, but over time. Even with every intent to maintain stability, this happens, but if you allow that URI stability is somehow less important than other conveniences, then I think all hope is lost for information continuing to be accessible. As for the difficulty of designing a consistent URI naming scheme for all time, the W3C position explicitly recognizes this, and this is why they recommend incorporating dates near the the root of the URI path. That way, fashions can change without requiring that pages published using older conventions be removed. How to do this in a wiki, I'm not sure, though I don't take that to mean we shouldn't try. I think the mediawiki mechanism you mention is reasonable if not ideal, though this would clearly be overwhelmed if page-renaming were to become the norm. There are, as you indicate, other technical concerns. But I still think they are more easily solved that the problems that arise by failing to maintain URI stability. Best regards, #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact

3 4

Emulating bash pipe/ process lib
by Marc Weber Marc Weber 22 Feb '06

22 Feb '06

Hi. I want to write a little haskell program executing about 4 programs passing data via pipes. As my python script seems to be slower than a bash script I want to try a ghc executable now. It should invoke different parts of a text to speech chain. This way I have one interface then. Talar und #haskell told me that I might use runProcess and pass handles for stdin and out created by createPipe and fdToHandle. So my simple test looks like this: module Main where import System.IO import System.Posix.IO main = do (fdIn,fdOut) <- createPipe let (iohIn, iohOut) = (fdToHandle fdIn, fdToHandle fdOut) hIn <- iohIn hOut <- iohOut hPutStr hIn "test" line <- hGetLine hOut print line -- should now print test having been piped through my pipe but I get the error: pipe2: <file descriptor: 3>: hPutStr: illegal operation (handle is not open for writing) And in current CVS docs in base.System.Process.hs it is said that createPipe is no longer exported ? I've also found this library: http://www.haskell.org/communities/11-2005/html/report.html#processlib which seems to do something similar but is meant to pipe haskell types between different threads (? I haven't understood what's going on there because I can't understand Russian ;-) Is this of any help for me? Greetings Marc

6 12

getChar + System.Cmd.system + threads causes hangups
by Einar Karttunen 22 Feb '06

22 Feb '06

Hello Using system or any variant of it from System.Process seems broken in multithreaded environments. This example will fail with and without -threaded. When run the program will print "hello: start" and then freeze. After pressing enter (the first getChar) System.Cmd.system will complete, but without that it will freeze for all eternity. What is the best way to fix this? I could use System.Posix, but that would lose windows portablity which is needed. import Control.Concurrent import System.Cmd main = do forkIO (threadDelay 100000 >> hello) getChar getChar hello = do putStrLn "hello: start" system "echo hello world!" putStrLn "hello: done" - Einar Karttunen

3 4

Re: Array interface refactoring
by bulat.ziganshin＠gmail.com 22 Feb '06

22 Feb '06

Hello Alson, Tuesday, February 21, 2006, 11:33:49 PM, you wrote: AK> As a Haskell new-ish-bie, the various Array interfaces AK> seem a bit inconsistent and make learning/using arrays AK> complicated. I *do* understand how to use arrays in AK> Haskell, but I think that the interface could be AK> cleaned up. sorry, but i think that you don't understand the whole situation. btw, are you read http://haskell.org/haskellwiki/Arrays ? AK> Examples of current confusions: AK> IArray and Array are dupes (obvious); Array is a type constructor, while IArray is a class AK> listArray for IArray, but newListArray for MArrays; AK> "!" for IArray, but readArray for MArrays. they have different types (!) :: IArray -> Ix -> Element readArray :: MArray -> Ix -> IO Element can you unify these two operations - one monadic and one pure to common type signature? AK> Proposal: I would propose the following for Haskell': AK> "Array" is the interface for arrays; drop IArray; AK> "MArray" is the interface for arrays in monads (IO, AK> ST, etc); and these two interfaces should support operations with the same names but different types? :) i partially agree with your other suggestions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0