April 2002 - Haskell-Cafe

Theorems for free.
by Long Goodbye 14 Apr '02

14 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 14 Apr '02

14 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 14 Apr '02

14 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 08 Apr '02

08 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 08 Apr '02

08 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

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

08 Apr '02

Thanks, but it still does not help... > Well, you've removed the parentheses that give you the > information you want. > Yes, I overlooked the parentheses. I meant what you said below: > foldl (++) [] [[1],[2],[3],[4]] ... > -> (((([] ++ [1]) ++ [2]) ++ [3]) ++ [4]) > > now you have to ask what has to be evaluated in order to get > the head of the result. > > 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. > I understand that I have to evaluate all that to get the head of the result, I just do not see how this ends up being quadratic. I have no problem seeing that if each function's argument had to be evaluated before the function is called but this is not the case here, right? To simplify, lets have (([] ++ [1]) ++ [2]) ++ [3]. To get the head of result (++) is called recursively three times. The last invocation returns [1] because its left argument is []. The invocation before it (... ++ [2]) receives [1], and can return (1:..) now, so it does. It does not finish constructing its whole result before something is returned to (... ++ [3]). Here is the root of my misunderstanding. The way I see it is that every time an element is output by (++) at the bottom of the invocation chain, it is propagated up the chain. No? konst

2 1

Re: Parsec: No newline after last line and 'many'
by Iavor Diatchki 08 Apr '02

08 Apr '02

hello, does this work? > pLine = many (noneOf "\n") > pLines = pLine `sepEndBy` char '\n' bye iavor On Sun, Apr 07, 2002 at 07:44:42PM +0200, Till Doerges wrote: > Hi folks, > > when trying to write a parser for unix-style textfiles, I stumbled > across the problem having to distinguish between lines w/ a newline > character at the end and lines w/o a newline at the end (i.e. the last > line in a file doesn't have to have it). > > Eventually I want to be able to use my parser 'linep' with 'many' on > no matter which text-files. > > The first version I tried, was > > --- snip --- > skip1 :: Parser() > skip1 = do > anyChar > return() > > linep :: Parser(String) > linep = do { cs <- many (noneOf "\n") > ; skip1 > ; return cs > } > --- snap --- > > Well, this only works, if the last line in the file is also terminated > by '\n'. So, I tried to be smarter using: > > --- snip --- > lineWith :: Parser(String) > lineWith = try (do { cs <- many (noneOf "\n") > ; skip1 > ; return cs > }) > > lineWithOut :: Parser(String) > lineWithOut = many anyChar > > linep :: Parser(String) > linep = lineWith > <|> lineWithOut > <?> "line" > --- snap --- > > But this doesn't do the trick either, instead it'll overflow my stack > if used in conjunction w/ 'many': > > --- snip --- > parse (do {many linep}) "stdin" (unlines ["hallo","ballo"]) > ^CInterrupted. > ReadOrig> parse (do {many linep}) "stdin" ("hallo\nballo") > ^CInterrupted. > --- snap --- > > Avoiding many OTOH works fine: > --- snip --- > parse (do {linep;linep}) "stdin" (unlines ["hallo","ballo"]) > Right "ballo" > ReadOrig> parse (do {linep;linep}) "stdin" ("hallo\nballo") > Right "ballo" > --- snap --- > > Besides these two attempts explicitly spelled out I've made quite a > few others, but none of them did the trick. > > The documentation for 'try' says that it'll only consume input upon > success, but why doesn't it work w/ 'many'? > > I know about the Prelude-functions unlines, lines etc., but they don't > really help, since linep should be used within another parser of mine. > > I am using Parsec as of Jan 25, 2001 (the version included w/ ghc 5.02). > > Any hints/solutions/... would be greatly appreciated! > > Bye -- Till > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell -- ---------------------------------------+---------------------------------------- Iavor S. Diatchki | email: diatchki(a)cse.ogi.edu Dept. of Computer Science | web: http://www.cse.ogi.edu/~diatchki OGI School of Science and Engineering | work phone: 5037481631 OHSU | home phone: 5036434085 ---------------------------------------+----------------------------------------

1 0