- Haskell-Cafe - Haskell.org

Picking a shell for runCommand
by Tom Hawkins 01 Mar '06

01 Mar '06

It appears runCommand uses /bin/sh by default, but our environment needs tcsh. Is there any way to set an alternative shell? -Tom

2 1

socket TChan problem
by Stefan Aeschbacher 01 Mar '06

01 Mar '06

Hi I try to write a program that reads from a socket and communicates the result over a TChan and writes it to stdout. Somehow I can't seem to get it right, the result is only printed when I send ETX on the socket. Attached is a sample program that shows the behvaviour. Any hints on where my error is or how I could debug such a problem is appreciated. regards Stefan

2 3

standard poll/select interface
by Bulat Ziganshin 28 Feb '06

28 Feb '06

Hello John, Thursday, February 09, 2006, 3:19:30 AM, you wrote: >> JM> If we had a good standard poll/select interface in System.IO then we >> JM> actually could implement a lot of concurrency as a library with no >> JM> (required) run-time overhead. I'd really like to see such a thing get >> JM> into the standard. Well, mainly it would just be a really useful thing >> JM> to have in general. If others think it is a good idea I can try to come >> JM> up with a suitable API and submit it to the repo. >> >> i have delayed answering to this letter until i announced my Streams >> library. now i can say that such API already exists - in terms of my >> library you need just to write an transformer that intercepts >> vGetBuf/vPutBuf calls and pass them to the select/poll machinery. so >> you can write such transformer just now and every program that uses >> Streams will benefit from its usage. Converting programs that use >> Handles to using Streams should be also an easy task. JM> I was actually asking for something much more modest, which was the JM> routine needed to pass them to the select/poll machinery. but yeah, what JM> you say is one of my expected uses of such a routine. Once a standard IO JM> library settles down, then I can start working on the exact API such a JM> routine would have. but if all will wait while the library settles down, it will never occur :) your work can change design of library, like the my library itself can change the shape of haskell' :) at this moment, i just developed the library which satisfy demands in extending current I/O library by new features, such as Unicode support, high speed, portability to other compilers, binary i/o, i/o for packed strings, and asynchronous i/o using methods other than select(). but i don't implement all these features actually, i just developed infrastructure, in which all these features can be easily added. unlike the System.IO library, you don't need to ask someone to implement new features or make corrections in foreign sources. you just need to develop module what implements this standard Stream interface and then it can be used as easy as transformers from the library itself as i understand this idea, transformer implementing async i/o should intercept vGetBuf/vPutBuf calls for the FDs, start the appropriate async operation, and then switch to another Haskell threads. the I/O manager thread should run select() in cycle and when the request is finished, wake up the appropriate thread. what's all. if you will ever need, this implementation can then be used to extend GHC's System.IO internals with the support for new async i/o managers (as i understand, select() is now supported by GHC, but poll(), kqueue() is not supported?). the only difference that my lib gives an opportunity to test this implementation without modifying GHC I/O internals, what is somewhat simpler. so, interface for async vGetBuf/vPutBuf routines should be the same as for read/write: type FD = Int vGetBuf_async :: FD -> Ptr a -> Int -> IO Int vPutBuf_async :: FD -> Ptr a -> Int -> IO Int i think that implementations for ghc and jhc should be slightly different, though, because of different ways to implement multi-threading. but the I/O manager should be the same - it just receives info about I/O operations to run and returns information about completed ones. ... well, this I/O manager should implement just one operation: performIO :: Request -> IO () type Request = (IOType, FD, Ptr a, Int, Notifier) data IOType = Read | Write | ... type Notifier = Result -> IO () data Result = OK Int | Fail ErrorInfo "performIO" starts new I/O operation. On the completion of this operation, Notifier is called with information about results of execution. so, for the GHC the following should work: vGetBuf_async fd ptr size = do done <- newMVar let notifier = putMVar done () performIO (Read, fd, ptr, size, notifier) takeMVar done for JHC, the body of "vGetBuf_async" may be different if you will find this interface reasonable, at least for the first iteration, i will develop appropriate transformer, so for you remains "only" the implementation of "performIO" >> of course, Streams library is not some standard just now, and moreover >> - it is not compatible with JHC. the greatest problem is what i using >> type classes extensions available in GHC/Hugs what is not in H98 >> standard. so, i'm interested in pushing Haskell' to accept most >> advanced possible extensions in this area and, of course, in actual >> implementing these extensions in the Haskell compilers. alternative >> way to make Streams available to wider range of Haskell compilers is >> to strip support of streams working in monads other that IO. JM> Don't take the absence of a feature in jhc to mean I don't like or want JM> that feature. There are a lot of things I don't have but that I'd JM> definitly want to see in the language simply because I was only shooting JM> for H98 to begin with and was more interested in a lot of the back end JM> stuff. You should figure out the nicest design that uses just the JM> extensions needed for the design you want. it could help us decide what JM> goes into haskell-prime to know what is absolutely needed for good JM> design and what is just nice to have. this simply means that the Streams library cannot be used with JHC, what is bad news, because it is even more rich than GHC's System.IO. jhc had chance to get modern I/O library. but it lost that chance :) >> if you can make select/poll transformer, at least for testing >> purposes, that will be really great. JM> Yeah, I will look into this. the basic select/poll call will have to be JM> pretty low level, but hopefully it will allow interesting higher level JM> constructs based on your streams or an evolution of them. please look. at this moment Sreams library lacks only a few important features, already implemented in GHC's System.IO: sockets, line buffering and async i/o. moreover, i don't have an experience in implementing the async i/o, so foreign help is really necessary addressing these three issues will allow to propose the Streams library as possible System.IO replacement. and as you can see, implementing the "performIO" will allow us to use async i/o for all possible i/o operations, including "get/put_" or vGetContents, for example -- Best regards, Bulat mailto:bulatz@HotPOP.com

8 18

Associated Type Synonyms question
by Niklas Broberg 28 Feb '06

28 Feb '06

Hi, I'm playing around with associated type synonyms (ATS) [1] and the PHRaC interpreter, trying to model existing uses of FDs. I really enjoy working with ATS, but I've come across a situation that I don't quite know how to handle, or indeed if it can be handled at all. The scene is Control.Monad.Writer from mtl, where we can find the following definition (simplified for presentation): class (Monoid w, Monad m) => MonadWriter m w | m -> w where tell :: w -> m () The class MonadWriter has two type parameters, one for the monad itself and the other for that which is written. The Monoid constraint on the output is (I guess) there only as a documentation of sorts, stating that the intention is that the output of subsequent tell's should be combinable using mplus. A simple custom monad that just does output could be written as: data MyWriterM w a = MyWriterM (a, [w]) instance Monad (MyWriterM w) where return x = MyWriterM (x, []) MyWriterM (a, xs) >>= k = let MyWriterM (b, xs') = k a in MyWriterM (b, xs ++ xs') instance MonadWriter (MyWriterM w) w where tell x = MyWriterM ((), [x]) Now, to model this using ATS we would write, ignoring the Monoid constraint, the following class declaration*: class Monad m => MonadWriter m where type Output m tell :: Output m -> m () instance MonadWriter (MyWriterM w) where type Output m = [w] tell x = MyWriterM ((), [x]) This works fine, but the obvious question is then, where to put back the Monoid restriction? This time we want the type Output m to be constrained, so my naive first guess was to write: class (Monad m, Monoid (Output m)) => MonadWriter m where .. but phrac says "illegal context for class MonadWriter: only type variables can be constrained". I can't really think of anywhere else to put the restriction, other than making up an ad hoc class constraint syntax for associated types like class Monad m => MonadWriter m where type (Monoid) Output m ... My first question is already stated: where do I put the Monoid constraint? But since I suspect the answer is "you don't", a number of followup questions spring to mind: - why not? Apart from possibly having to use some ugly syntax for it, are there any fundamental reasons why this should not be allowed? - when looking at the definition of MonadWriter the Monoid constraint is not strictly necessary, and none of the other mtl monads have anything similar. Is it the assumption that this kind of constraint is never really necessary, and thus no support for it is needed for ATS? Hope someone can shed some light on this matter :-) Regards, /Niklas [1] http://www.cse.unsw.edu.au/~chak/papers/CKP05.html * Using Haskell syntax instead of the PHRaC equivalent

11 27

-fno-monomorphism-restriction makes type-inference ambiguous?
by Eike Scholz 28 Feb '06

28 Feb '06

Note: This Question has already been asked on the haskell mailing list. But haskell-cafe seems to be more adequate for for this question. Hi, i have encountered a problem and I don't quite understand the reason why I get the results I get. ghci seems to infer different types for the same expression. Consider that I have disabled the monomorphism restriction in module AGC.lhs (which is attached). and I have a toplevel definition of: > mylength = synAttr listLength loding the module in ghci (6.4) gives (beside some correct warnings): $ Ok, modules loaded: Main. $ *Main> :type synAttr $ synAttr :: (Data b) => ((?stack::[Dyn]) => b -> a) -> Attr a $ *Main> :type listLength $ listLength :: (?stack::[Dyn]) => List -> Float $ *Main> :type (synAttr listLength) $ (synAttr listLength) :: Attr Float $ *Main> :type mylength $ mylength :: (?stack::[Dyn]) => Dyn -> Dyn -> [Dyn] -> Maybe Float $ *Main> let mylength = synAttr listLength $ *Main> :type mylength $ mylength :: Dyn -> Dyn -> [Dyn] -> Maybe Float where > type Attr a = Dyn -> Dyn -> [Dyn]-> Maybe a the problem I have is that inferred types for the toplevel declaration mylength differ from the verbatim equal definition in the Let experssion. for the toplevel it infers: mylength :: (?stack::[Dyn]) => Dyn -> Dyn -> [Dyn] -> Maybe Float for the let-Binding mylength :: Dyn -> Dyn -> [Dyn] -> Maybe Float and this is what I expected. Has anyone an Idea, why this happens? best regards, Eike Scholz PS: Beware of the comments in the attached file. This file is under heavy development. I am dyslexic and don't correct the comments while continuously rewriting code and comments. I hope that the comments are useful anyway. The (+>) (~>) (#>) operators are broken at the moment and don't work the way intended.

2 1

Question about Haskell types
by Pete Chown 27 Feb '06

27 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 26 Feb '06

26 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