- Haskell-Cafe - Haskell.org

Help need "Cannot use type synonym in instance head"
by Benny 14 Apr '02

14 Apr '02

type Poly = [Float] addPoly::Poly->Poly->Poly addPoly x y = zipWith (+) x y instance (Float a) => Num (Poly a) where (+) = addPoly I got the error message "Cannot use type synonym in instance head" when I was trying to compile the codes above. Can anyone tell me why and how to solve it? Cheers Benny

2 1

Re: Help need "Cannot use type synonym in instance head"
by Ashley Yakeley 14 Apr '02

14 Apr '02

At 2002-04-13 21:22, Benny wrote: >type Poly = [Float] > >addPoly::Poly->Poly->Poly >addPoly x y = zipWith (+) x y > >instance (Float a) => Num (Poly a) where > (+) = addPoly > > >I got the error message "Cannot use type synonym in instance head" when I >was trying to compile the codes above. Can anyone tell me why and how to >solve it? There are at least two errors here. Firstly the context of your instance "(Float a) =>" is wrong. "Float" is not a class. Secondly, "(Poly a)" is meaningless, since Poly is a type and does not take any parameter. -- Ashley Yakeley, Seattle WA

1 0

Theorems for free.
by Long Goodbye 13 Apr '02

13 Apr '02

I have heard that Philip Wadlers article "Theorems for free" has been written in a "CT terms" version in addition to the one that can be found at Nec. If this is the case then I would very much like to have a pointer to where this file can be found. Thank you, Henrik Ljung _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

1 0

writeFile and buffering
by Jorge Adriano 13 Apr '02

13 Apr '02

Hi, Is there any way to use writeFile with no buffering? I know that with handles I can do, > hSetBuffering hdl NoBuffering Since all I do is write a string to a file, I don't see much need for handles here though. I wanted no buffer to be able to check the status of the program by accessing the file - I calculate thousands of values, but just write few hundred so it usually ends up just writing the string in the very end. Thanks in advance J.A.

1 0

Re: Bug in IO libraries when sending data through a pipe?
by Manuel M. T. Chakravarty 13 Apr '02

13 Apr '02

Jens Petersen <juhp(a)01.246.ne.jp> wrote, > Jens Petersen <petersen(a)redhat.com> writes: > > Also I just rediscovered Manuel Chakravarty's HPL (Haskell > Ports Library), which provides a rather elegant, > sophisticated approach. > > http://www.cse.unsw.edu.au/~chak/haskell/ports/ > > It compiles fine under ghc-5.02.2, and using the BufferMode > patch included at the end output seems to be ok, Why LineBuffering? Doesn't really change anything for me (same GHC version). > but input > of more than 2048 bytes doesn't seem to be being handled > reliably. [..] > mostly gives no output, but occasionally I see > > Warning: Ports.listenToPort: Attempted to listen to a closed port! > > Needs some debugging I guess. :) I guess, it needs more documentation. Your test program is wrong in two places. The function `listenToPort' starts to listens at the given port exactly when `listenToPort' is executed; ie, any data that goes over the port earlier will not be received in the stream that this call to `listenToPort' returns. You wrote > outpt <- newPort ' ' > errpt <- newPort ' ' > let p = proc cmd args > p inpt outpt errpt > putStrLn "output:" > out <- listenToPort outpt As the processes `cmd' is fork()ed in a separate thread, it may already have finshed its business until you get to `listenToPort outpt', which means you have missed all the data. For similar reasons > errclosed <- isClosedPort errpt > unless errclosed $ > do > err <- listenToPort errpt isn't recommended. I changed your program to what I have appended. It then works for me for the % cat 4096 | test-processes cat test...except that I sometimes get a "Broken Pipe". So, I guess, I have to do some debugging after all (plus improve the documentation). Cheers, Manuel PS: I'll add your program to the ports/tests/ directory if you don't mind. -=- module Main where import Processes import Ports import IO (openFile, hGetContents, IOMode(..), hSetBuffering, BufferMode(..)) import Monad (unless) main :: IO() main = do inpt <- getContents withPorts [] $ \ (cmd:args) -> do outpt <- newPort ' ' errpt <- newPort ' ' out <- listenToPort outpt err <- listenToPort errpt let p = proc cmd args p inpt outpt errpt putStrLn "output:" mapM_ putStrLn $ lines out putStrLn "error:" putStr err putStrLn "test finished"

2 1

recursive function
by excellent2002 11 Apr '02

11 Apr '02

Hi,I want to write a recursive function to change list as this form ["whantever","\n","it is","\n","I","don;t","care"] to ["whatever","it is","I \n don't \n care"], but I failed to work it out. Anybody can help me ? Thank you very much If there is no "\n",between the strings, add "\n" beteen them and merge these string. Regards Alan ----------------------------------------- ÒÚÌÆÉú»îÆ·ÅÆµÚÒ»Ö÷Žò http://bag.etang.com/payment_1.htm ÒÚÌÆ¶ÌÐÅ£¬ÄúÌùÉíµÄÊ±ÉÐ¹ËÎÊ http://sms.etang.com Ã¿ÌìÈÃÄãÇáËÉŒÇµ¥ŽÊ http://www.etang.com/texthanburg/index.htm ÃÀ¹úŽóÑ§Ö®ÃÅÎªÄã¶ø¿ª °Ù·Ö°ÙÄÃœ±Ñ§œð http://campus.etang.com/html/academic/usa/scho/scho017.htm

1 0

subscribe
by Leif Eriksen 09 Apr '02

09 Apr '02

Leif Eriksen Software Engineer AusRegistry Pty Ltd Level 12, 10 Queens Rd. Melbourne, Victoria. Australia 3004. Ph: +61 3 9866 1990 Fax: +61 3 9866 1970 Email: leif(a)ausregistry.com.au Web: www.ausregistry.com.au Registrars: www.ausregistry.net.au

1 0

subscribe
by Leif Eriksen 09 Apr '02

09 Apr '02

Leif Eriksen Software Engineer AusRegistry Pty Ltd Level 12, 10 Queens Rd. Melbourne, Victoria. Australia 3004. Ph: +61 3 9866 1990 Fax: +61 3 9866 1970 Email: leif(a)ausregistry.com.au Web: www.ausregistry.com.au Registrars: www.ausregistry.net.au

1 0

RE: if (++) were left associative ?
by Konst Sushenko 07 Apr '02

07 Apr '02

> > I don't think so. I think it only takes linear time to get the head. > But once you've gotten the head, it takes linear time again to get the > head of the tail, .... You get (I think...) a progression like > n+(n-1)+(n-2)+...+1, which is in O(n^2). > What does 'n' denote? The get the head, it takes time proportional to the number of (++) invocations. Is that what you mean? konst

2 1

RE: if (++) were left associative ?
by Konst Sushenko 07 Apr '02

07 Apr '02

This one helped. Thanks. 'reduction' was the key word that made it clear for me. It is not that left associated (++) reconstructs the list once and again (although one can say that) it is just that to return the head from the recursive invocations takes quadratic number of reductions. Right? konst > -----Original Message----- > From: Jay Cox [mailto:sqrtofone@yahoo.com] > Sent: Sunday, April 07, 2002 11:09 AM > To: Konst Sushenko > Cc: haskell-cafe(a)haskell.org; Jon Fairbairn > Subject: Re: if (++) were left associative ? > > > On Sun, 7 Apr 2002, Jon Fairbairn wrote: > > > The answer is that you have to evaluate ((([] ++ [1]) ++ > > [2]) ++ [3]) before you can find it, and to get that, you > > have to evaluate (([] ++ [1]) ++ [2]) and so on. > > > > > > In the other case, you can get the head of (a:...)++ (b ++ > > c) by evaluating only the first steps of the first (++). > > > > > > Does that help? > > > > Jón > > > > > Just to add a bit. "evaluate" is such a fuzzy word, > especially in a lazy > language. You must know the context of the expression in > order to know > how much of it is actually evaluated*. > > (* Eventually, the context of all expressions in haskell will be the > evaluation of something in the IO monad, but generally you don't > have to go that far in your reasoning about contexts and stuff.) > > > Ok. I shall now attempt to explain a bit more deeply the differences > between the evaluation expressions which use a left associative append > versis expressions uing a right associative append. > > > > > > In the following,"tail" means any arbitrary tail of a list. > Also, for the > sake of argument, assume : binds closer than ++ and function > application > so we dont have to mess with so many damn parentheses. (in > reality I don't > think anything binds closer than function application in Haskell.) > > the definition of ++ is like > > [] ++ b = b > (l:ls) ++ b = l:(ls++b) > > > applist = ((w:tail ++ x:tail) ++ y:tail) ++ z:tail > > This can be rewritten as the following, so we can litterally see > the leftmost-outermost-reduction. > > applist = (++) ((++) ((++) w:tail x:tail) y:tail) z:tail > > ick! lets say f=(++) (or that f is the same function as the append > operator (++)) > > applist = f (f (f w:tail x:tail) y:tail) z:tail > > > > Alright. Now say we want the head of this applist. So lets use > the head function. > > head patern matches against that thing, causing > a reduction of the outmost f. Since f > pattern matches against its first arguement, > it must cause a reduction in the second f > in that expression, and likewise the third f. > The third f will succeed in its pattern match, > namely (w:tail). > > Now, f, which was (++), will get unfolded. > using the original definition of (++) > (l:ls) ++ b = l:(ls++b) > > this becomes > (w:tail) ++ (x:tail) = w:(tail ++ x:tail) > > (which in our notation is w:(f tail x:tail)) > > substuting our unfolding back into applist and continuing with > reductions: > > f (f (f w:tail x:tail) y:tail) z:tail > -> f (f w:(f tail x:tail) y:tail) z:tail > -> f w:(f (f tail x:tail) y:tail) z:tail > -> w:(f(f(f tail x:tail) y:tail) z:tail) > > so its not like it will take length (w:tail) + length (x:tail) + > length(y:tail) reductions or whatever, but it does take > 3 reductions to get to the head, AND WILL BY NECESSITY take 3 > reductions to get each element of the rest of the tail of w:tail. > > I >think< in the end, if you need all of applist, you will need > something like > > 3*length (w:tail) + 2*length(x:tail) + length(y:tail) > > reductions of f. > > That is definitely NOT linear with > (length x:tail) + (length y:tail) + (length z:tail) > > > > > Now. Lets try go get the head of > > w:tail ++ (x:tail ++ (y:tail ++ z:tail)) > > doing like before with (++), that is > > f w:tail (f x:tail (f y:tail z:tail)) > > and now f pattern matches, etc. > > > ->w:(f tail (f x:tail (f y:tail z:tail))) > > > and thats the ONLY reduction necessary. > > getting all of applist should only require something close to > > (length x:tail) + (length y:tail) + (length z:tail) > > reductions of f. > > > > I'm sure I'm not %100 accurate here, (and It's not worth the effort > for this message!) but I hope this gives more insight and not > more confusion! > > Cheers, > > > Jay Cox > > >

2 1