- Haskell-Cafe - Haskell.org

Re: An IO Question from a Newbie
by Jon Cast 22 Sep '03

22 Sep '03

> On Fri, 12 Sep 2003 16:27:59 -0600 > Matt O'Connor <angagon(a)earthlink.net> wrote: > > > Hello all. I'm new to functional programming and Haskell, but have > > been programming in C and Java for a while. I've been going through > > the tutorials and whatnot on haskell.org. I've read from the Gentle > > Introduction to Haskell about IO and some of the other stuff and I > > have a question about it. > > > > main = do putStr "Type Something: " > > str <- getLine > > putStrLn ("You typed: " ++ str) > > > > When compile and run this code the "Type Something: " isn't displayed > > until the putStrLn. So there is no prompt. The output looks like > > this. > > > > s > > Type Something: You typed: s > > > > But if I change the putStr "Type Something: " to a putStrLn or put a > > \n at the end of the string it displays the text immediately (ie, when > > I want it to). Is there a good reason for this? Am I doing something > > wrong? Or do I need to call some kind of standard output flush? > > Yes, the problem is that the first line is not being flushed. Importing > hFlush and stdout from IO (or System.IO) and adding hFlush stdout after > you putStr will fix it. Alternatively, you could change the buffering > on stdout to NoBuffering. I don't know if there is a standard > putStrWithFlush function or just a better answer than this. A > putStrWithFlush would be trivial to write or more generally to a > HOF that flushed after performing the action passed to it. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just thought I'd point out (in case it isn't clear) that this function is flushAfter h a = liftM2 const a (hFlush h). Not much of an improvement... Jon Cast

1 0

(Off-topic) Question about categories
by Graham Klyne 19 Sep '03

19 Sep '03

(I'm asking here because I believe there is some overlap between category theory and functional programming cognoscenti...) It has been suggested to me that categories may be a useful framework (more useful than set theory) for conceptualizing things for which there is no well-defined equality relationship. (The discussion is about resources in WWW.) I've done a little digging about category theory, and find some relatively approachable material at: http://www.wikipedia.org/wiki/Category_theory http://www.wikipedia.org/wiki/Class_(set_theory) and nearby. But I'm hitting a mental block with this (and other places I've look don't add anything I can grok). The definition of a category depends on the definition of a morphism, and in particular the existence of an identity morphism for every object in a category. The definition of an morphism is in terms of equality of compositions of morphisms: for f : A -> B we have Id[B]. f = f = f . Id[A] My problem is this: how does it make sense to define an equality of morphisms without some well-defined concept of equality on the underlying objects to which they apply? That is, given object X and an object Y, it is possible to examine them and determine whether or not they are the same object. And if the underlying objects have such a concept of equality, what prevents them from being sets or members of sets? But categories are presented as being more general than sets. Does anyone see the cause of my non-comprehension here? #g ------------ Graham Klyne GK(a)NineByNine.org

6 5

How to detect finite/infinite lists?
by Juanma Barranquero 19 Sep '03

19 Sep '03

Extremely-newbie questions: Is there any way to know if a list is finite or infinite, other than doing: length l and waiting forever? :) I ask because I was learning Haskell by writing some pretty naive implementation of surreal numbers, where I used lists for left and right surreal sets, and I wanted to do some operations on the sets (like finding the maximum/minimum), but obviously just on finite sets. I vaguely suspect the answer is going to be: "No, because lists are lazy (at least when they are :) and there's no general way to know beforehand how many elements they're going to have". But still, if I write x = [1..5] the compiler knows pretty well x is not going to grow any new member... (Unrelated) Is there any standard function to do: interleave [] _ = [] interleave _ [] = [] interleave (x:xs) (y:ys) = x : y : interleave xs ys It's pretty easy to implement as shown or via zipWith, but given that Haskell 98 already includes some "basic" functions (like cycle, iterate, etc.) I wonder if I've missed this one somehow. Thanks, /L/e/k/t/u

4 5

Re: How to detect finite/infinite lists?
by Juanma Barranquero 19 Sep '03

19 Sep '03

On Thu, 18 Sep 2003 14:20:46 -0400, "David Barton" <dlb(a)patriot.net> wrote: > that's halting problem equivalent. Yes, I know it's a halting problem, in the general case. But the compiler could try to say if it knows it *is* a finite list. So: x = [1..10] y = [1..] z = someFunctionOrOther knownToBeFinite x -> should return Just True knownToBeFinite y -> should return Just False knownToBeFinite z -> should return Nothing ("I don't know"). or something along these lines. > Nope. Ok. Thanks, /L/e/k/t/u

1 0

RE: Fast I/O with sockets
by Simon Marlow 18 Sep '03

18 Sep '03

> I was wondering how to read and write from a Socket in the most > performant way. According to the library documentation from GHC, > 'hGetBuf' and 'hPutBuf' are the way to go. But my problem with these > functions is that they expect to read exactly the number of bytes I > gave them! > > The IO computation > > hGetBuf sock ptr 1024 > > wants to read 1024 bytes, no less. This doesn't work for me, because I > need to drive an interactive line-based protocol session. I need the > read operation to consume as much data as is available and then to > return immediately, so that I can process the command right away. > > As an alternative, I looked at 'hGetLine', but this doesn't work for > me either, at least not very well, because in my protocol, lines are > terminated by "\r\n" -- not just "\n", like hGetLine expects it. hGetLine should work fine, indeed that's what I used in the Haskell Web Server. Each line will have an extra '\r' at the end, but you just need to allow for that. We really should have non-blocking versions of hGetBuf and hPutBuf, and in fact I have the code sitting in my tree. I'll take a look and see if it can be committed. Cheers, Simon

2 1

Re: Improvement on this function
by Jon Fairbairn 17 Sep '03

17 Sep '03

On 2003-09-17 at 10:31EDT Gordon James Miller wrote: Something I think is more café than language: > Hello all. > > I'd be interested in getting some feedback on how to do this linear > interpolation function a little more cleanly. The normal way that this > is taught is to find the set of indices in the x list that bracket the > input value, then use the slope between these points to calculate the y > value for the input value. > > I had a version working at one point using !! to access particular > elements but I wasn't sure which one was the better solution. !! can be expensive. > linterp :: [Double] -> [Double] -> Double -> Double > linterp (x1:x2:xs) (y1:y2:ys) x > | x <= x2 || xs == [] = linterpPair x1 x2 y1 y2 x > | otherwise = linterp (x2:xs) (y2:ys) x > where linterpPair x1 x2 y1 y2 x = x1 + (x - x1) * (y2 - y1) / (x2 - > x1) It seems to me that you have too much going on in one function. It would be better to break it into the part that finds the point where the interpolation is supposed to happen and the function that does the interpolation. You sort-of do this, but don't go far enough for my taste. You don't say whether the xs are supposed to be in increasing order. Also it's not obvious that your version does the right thing in the case where x < head xs, and linterpPair doesn't look right to me. Something like: linterp :: [Double] -> [Double] -> Double -> Double linterp xs ys x = linterpPair (neighbours (zip xs ys)) where linterpPair ((x1,y1),(x2,y2)) = y1 + (x - x1) * (y2 - y1) / (x2 - x1) neighbours all@(p@(x1,y1):rest) | x >= x1 = head (dropWhile ((<x). fst . snd) (all `zip` rest)) would be more to my taste, though it would be better to handle the errors rather than leave them to the runtime system. I think I would also define the function as linterp :: [(Double, Double)] -> Double -> Double since that seems more natural as the data are connected that way, and it would eliminate a zip. -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

1 0

Querying DNS from Haskell
by Peter Simons 16 Sep '03

16 Sep '03

Hi, is anyone aware of a library for Haskell, which allows to query domain name servers for MX, A, and PTR records in a non-blocking way? My first guess was to create an Interface to ADNS [1], but I figured, maybe someone else has already solved this problem? Peter [1] http://www.gnu.org/software/adns/

2 1

RE: simpler I/O buffering [was: RE: An IO Question from a Newbie]
by Simon Marlow 16 Sep '03

16 Sep '03

> Writing a sequence of characters across the interface I'm > proposing is a > request by the writing program for those characters to appear > at their > destination "soon". Ideally, "soon" would be "immediately"; > however, the > characters' appearance may deliberately be delayed ("buffered"), for > efficiency, as long as such delay is "unobtrusive" to a human > user of the > program. Buffering timeouts would depend on the device; for > a terminal, > perhaps 50-100 ms would be appropriate. Such an interval > would tend not > to be noticeable to a human user but would be long enough to > effectively > collect, say, an entire line of output for output "in one > piece". The use > of a reasonable timeout would avoid the confusing behavior where a > newline-less prompt doesn't appear until the prompted data is entered. So, let me see if I've understood: the situation would be exactly as now, except that the buffer automatically gets flushed if it stays non-empty for more than a certain time interval. I don't think I like it: whatever time interval you choose will be too long. If you're doing communication with another program, for example, you really don't want to have the dialog stalled for 100ms doing nothing. Sure, you could insert a flush, but only a programmer knowledgeable about buffering will know to do that, or a programmer who has debugged the program in detail to find out why it is sitting idle most of the time. So, in the end the programmer still needs to know about buffering. I'd prefer it if the program didn't work at all when the flush is missing, because it tells you immediately that something is wrong. Cheers, Simon

1 0

Fast I/O with sockets
by Peter Simons 16 Sep '03

16 Sep '03

Hi, I was wondering how to read and write from a Socket in the most performant way. According to the library documentation from GHC, 'hGetBuf' and 'hPutBuf' are the way to go. But my problem with these functions is that they expect to read exactly the number of bytes I gave them! The IO computation hGetBuf sock ptr 1024 wants to read 1024 bytes, no less. This doesn't work for me, because I need to drive an interactive line-based protocol session. I need the read operation to consume as much data as is available and then to return immediately, so that I can process the command right away. As an alternative, I looked at 'hGetLine', but this doesn't work for me either, at least not very well, because in my protocol, lines are terminated by "\r\n" -- not just "\n", like hGetLine expects it. Finally, I considered 'hGetContents', which has the nice property of returning a lazy-evaluated list of the data read from the socket. But unfortunately, I don't see how I could implement something like a "read timeout" on the socket when using this function. Any ideas, anybody? Peter

1 0

RE: An IO Question from a Newbie
by Simon Marlow 16 Sep '03

16 Sep '03

> > But there's one significant difference between C and > Haskell, which is > > applicable in the case of Matt's program. In C, any line-buffered > > output streams are automatically flushed when a read from an > > unbuffered or line-buffered stream can't be satisfied from > its buffer. > > Interesting. I didn't know this. Maybe we should match this > behaviour, or > provide a write-string-and-flush function. It seems like this issue > is causing an undue amound of trouble. I wrote GHC's IO library, and deliberately didn't include this feature. The previous version of the library did have such a feature, specifically for stdin/stdout. Note that the report doesn't say we must do this. The reason I didn't include the feature is because I can't see a way to do it right. Flushing *all* line-buffered handles (the ANSI C way) doesn't seem right. Flushing stdout just because we read from stdin is not right, because the two streams might refer to completely different I/O objects. Perhaps we should attempt to detect when there are two streams connected to the same I/O object (file, pipe, tty, whatever) and enable the magic flushing then. But now do I have to explain to people how this works? I suppose we could take the view that extra flushing is basically harmless, so it doesn't matter that we flush a bunch of Handles more often than we need to. The advantage of the current scheme is that it is easy to understand and explain; the library doesn't try to do clever stuff behind your back. The disadvantage is that it catches people out, and it sometimes requires you to import IO in an otherwise Prelude-only program. I'm more-or-less agnostic - if there's a way to avoid catching people out without introducing too much overhead or complicated rules that we have to explain, then I'll happily implement it. Cheers, Simon

3 2