September 2001 - Haskell-Cafe

gconsym
by Ian Lynagh 24 Sep '01

24 Sep '01

Just to make sure I am interpreting the report correctly, is ":" meant to be a valid qconop regardless of the precedence-level and associativity of the qconop? Thanks Ian

1 0

RE: Socket library from hslibs
by Simon Marlow 21 Sep '01

21 Sep '01

Chris Webb writes: > For simple networking, I usually find that the simple Socket interface > from hslibs does everything I need, except that I always need > to import > sClose from SocketPrim as well, so I can close the sockets I open. > Tidying up some old code this morning, I was wondering: is the absence > of sClose in the Socket interface accidental, or should I be disposing > of listening sockets some other way? No, I think you're right. Socket should really export sClose too. Perhaps it should be called Socket.close, or closeSocket? Cheers, Simon

1 0

Socket library from hslibs
by Chris Webb 21 Sep '01

21 Sep '01

For simple networking, I usually find that the simple Socket interface from hslibs does everything I need, except that I always need to import sClose from SocketPrim as well, so I can close the sockets I open. Tidying up some old code this morning, I was wondering: is the absence of sClose in the Socket interface accidental, or should I be disposing of listening sockets some other way? Cheers, Chris.

1 0

Re: let/where
by John Hughes 19 Sep '01

19 Sep '01

The point of where is that it scopes over guards and multiple equations as well as right hand sides. f x | xsquared < 1000 = xsquared | otherwise = 0 where xsquared = x*x For the same reason, it has to be restricted to appear at the "top level" of a right hand side. Of course, we also need a construct to bind local variables inside an expression -- hence let, which therefore cannot scope over guards. Two kinds of scope, two binding constructions. We could have got away with one, if we had thrown out guards and relied just on if-then-else to test conditions instead. But guards are very expressive: some programs would have been a lot harder to write without them. Typical examples are when we just want to pick out one case in the first equation of a function, before lots of pattern matching: f x y | simplecase x y = simpleanswer f p1 p2 = ... f p3 p4 = ... ... There's no neat way to write this with if-then-else: you need to split f into two functions f x y = if simplecase x y then simpleanswer else f' x y f' p1 p2 = ... ... That's the reason Haskell has two binding constructions. John Hughes

3 2

Re: let/where
by Norman Ramsey 19 Sep '01

19 Sep '01

> There was some debate about which to have - it's a matter of personal > preference and style. The problem is that if you have both let and where > in the expression syntax, then > > let a in b where c > > is ambiguous unless you make an arbitrary decision about the precedence, Was it not considered to forbid such ambiguous expressions, requiring explicit parentheses to resolve the ambiguity? Norman, who sometimes wishes `where' were a postfix `let', and not part of the declaration syntax (though he does not wish to give up scoping over multiple guards).

2 1

let/where
by Mark Carroll 19 Sep '01

19 Sep '01

There seem to be a few situations where it's not clear to me when to use "let" and when "where". For instance, in this little example I was playing with to work out what syntax works, main = putStr (show (if maybe_index == Nothing then DP_Unknown else DP_Number index) ++ "\n") where maybe_index = maybe_read word (Just index) = maybe_index or... main = let maybe_index = maybe_read word (Just index) = maybe_index in putStr (show (if maybe_index == Nothing then DP_Unknown else DP_Number index) ++ "\n") Does anyone care? At the moment I use "where" so that at a first glance you get an overall idea of things, then you can read further for details if you like. I was disappointed to find that I don't seem to be able to write things like, main = let maybe_index = maybe_read word in putStr (show (if maybe_index == Nothing then DP_Unknown else DP_Number index) ++ "\n") where (Just index) = maybe_index BTW, is the above a sane way of getting the 'index' 'out of' the "Just"? I often seem to be using a "where (Just foo) = bar" type of idiom. (Of course, there is that special "let" stuff for "do" notation too which doesn't seem to use "in".) I hope all that was somewhat coherent, anyway, or at least sheds light on some of the confusion of newcomers to Haskell! -- Mark

3 2

Subscribe
by John Miller 17 Sep '01

17 Sep '01

ProClarity Corporation John Miller Research & Development <mailto:jmiller@proclarity.com> jmiller(a)proclarity.com (208)344-1630 ext. 111

1 0

Re: Multiple applications of a function
by Marcin 'Qrczak' Kowalczyk 16 Sep '01

16 Sep '01

Sun, 16 Sep 2001 10:52:07 -0400 (EDT), Mark Carroll <mark(a)chaos.x-philes.com> pisze: > To multiply apply a function, I'm currently using: > > multiplyApply f n a = (iterate f a) !! n > > ...is there a Prelude function I've missed that already does this? Unfortunately not. > Could I be doing this better? I think an explicit recursion would make it easier to compile efficiently, and it can give a better error message for n < 0. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Multiple applications of a function
by Mark Carroll 16 Sep '01

16 Sep '01

To multiply apply a function, I'm currently using: multiplyApply f n a = (iterate f a) !! n ...is there a Prelude function I've missed that already does this? Could I be doing this better? -- Mark

1 0

Re: Application letters at the Haskell workshop: suggestion
by Ashley Yakeley 15 Sep '01

15 Sep '01

At 2001-09-15 08:31, Mark Carroll wrote: >AFAICS a simple way to get >out of this is to only have one exception type that carries no information >instead of different ones so we can't distinguish one exception from >another, but that's obviously not great. Isn't that what 'bottom' is? -- Ashley Yakeley, Seattle WA

2 1