- Haskell-Cafe - Haskell.org

RE: Haskell indentation
by Hal Daume 27 Aug '03

27 Aug '03

Just my 2 cents... > The first is that I always put the where for local function > definitions > on a new line, e.g. > foo x = x + a + b > where a = 1 + x > b = 2 * x > I find this a lot clearer and prettier than, > foo x = x + a + b where > a = 1 + x > b = 2 * x I used to do it your style, but have switched to: > foo x = x + a + b > where > a = 1 + x > b = 2 * x because it makes cut&paste easier. instance/class declarations for me also don't obey this. > data AST > = Const Int > | Var String > | Lam String AST > | App AST AST > | Let String AST AST > | Add AST AST same here. or for records, I like: > data Rec = > Rec { > foo :: Int, > bar, > bluff :: String > } > Another difficult case that I haven't solidified a style for is large > type signatures. I tend to do something like: > myfoo :: (Context1, Context2, Context3) => > type1 -> -- maybe a description of type1 > type2 -> > type3 -> > result type it takes a lot more vertical space, but you also have easy haddockability and it makes it a lot easier to remember what all those parameters are... - hal

1 0

ghc install redhat 7.3
by Mark Espinoza 27 Aug '03

27 Aug '03

Hello, I have been trying to install ghc on my redhat 7.3 system. I have about a 1.2 ghz processor. I got ghc-5.04.2 installed from an rpm. The ./configure for ghc-6.0.1 seemed to work fine. When I ran make it went for about an hour and a half, at which time it seemed to have been hung up for 15 or 20 minutes. I had to do other things so I stopped it and gave up for the day. Is it worth starting it before I go to bed, and see if it works by morning? What could I do to try to troubleshoot it? Is there an rpm for ghc-6.0.1? Thanks for your help. Sincerely, Mark Get your free e-mail address at http://felinemail.zzn.com __________________ http://www.zzn.com

2 1

Haskell indentation
by Per Larsson 27 Aug '03

27 Aug '03

Hi, I have problems finding a pleasing indentation style for haskell code. Especially nested do-blocks have a tendency to run away to the right margin. When looking on source code from experienced haskell programmers, there seems not to be any consensus at all, everyone uses their own convention and in many cases one changes style in the same module. Also, the automatic tools are problematic: the emacs mode I'm using bails out in certain contexts and there are few user customizations available. The haskell-src module in the GHC library offers a parser and pretty-printer for haskell code with nice options for customizing the indentation, but it can't handle comments which is a problem if you want to use it as a basis for implementing a indentation tool. Is there anyone who have given this some thought and have some suggestions for a consistent indentation style and/or desktop tools which I'm not aware of? Per

3 2

Homework
by thomas_bevan＠aardvark.net.au 26 Aug '03

26 Aug '03

Seeing as its thst time of year again and everyone is posting their homework, has anyone got any good puzzles to do? I wouldn't mind having a go at something a bit tricky. Tom

7 7

Re: Yet Another Monad Tutorial
by blaat blaat 26 Aug '03

26 Aug '03

To many questions, not enough mail. First, thanks for all your replies. Second, I stand totally corrected on the fact that we cannot break down monads. Functions of type m a->b are called impure, see also unsafePerformIO. I am questioning (a) the exact relation between monads, monadic IO, IO in general and (b) whether the impure restriction is actually a warranted restriction, which relates to, what I find, strange evaluation behavior of the IO monad. What is the difference between putStr "a", (putStr "a", putStr "a"), putStr (putStr "a"), putStr (show (putStr "a"))? At the moment objects of type IO a _only_ get evaluted when they are the _sole_ result of a Haskell program. What kind of strange dichotomy is that? Is not the _only_ interpretation of this dichotomy that objects of type IO describe impure programs (composed of actions which are only evaluated when...)? And, if so, why can't we decompose these programs (before they get evaluated)? And, if so, is not the only relation between a monad and doing functional IO that there is a monadic manner to construct descriptions of impure programs? If so, are there also non-monadic ways which might be equally interesting? As stated by Keith, deriving show for IO is possible. In such a setting putStr (putStr "a") I imagine returns "putStr \"a\"", which I find far more orthogonal than what we have now. (Have to find the reference still). Does this boil down to an impure or a pure decomposition? >From: Derek Elkins <ddarius(a)hotpop.com> >To: "blaat blaat" <l4t3r(a)hotmail.com>, haskell-cafe(a)haskell.org >pragmatic short one. > > > What did we lose? Well, introspection comes to mind. A monad is > > strange in the sense that, actually, there does not seem to be any > > reason to compute its value since we cannot possibly get anything out > > of it. In case of IO, only the haskell interpreter can. And, > > introspection is a nice thing to have, especially for compiler > > writers. Although I think the benefits in Haskell would be limited, an > > application might be that I could write my own promotion functions on > > my own programs. > >Lot's of issues with this paragraph, but here are the questions. What >do you mean by "promotion function"? Example of promotion: map f . map g = map (f . g) A promotion function would transform objects of type IO a into objects of type IO a while performing promotions. How would you write it in your >hypothetical Haskell? How is it related to IO? How do monads and/or the >IO monad in particular cause problems? Why couldn't the same be done >using monads or why would it be significantly harder if it can be done? In a monadic approach, I imagine functions like "unbind" which now would break purity. [..] > > I believe that central in the > > IO-issue is not the fact that we are using monads for IO - but that we > > can purely create impure programs which do the IO for us ;-), and that > > those do not have to be of the monadic kind. I still stand here (but am totally willing to be corrected on this account too). Hmpf, maybe someone more enlightened should write a paper on it. Cheers, l4t3r _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

3 2

AW: Haskell indentation
by Markus.Schnell＠infineon.com 26 Aug '03

26 Aug '03

If your code goes out to far right, it's a good idea to make a function out of it. > main = do > args <- getArgs > case args of > (fname:_) -> normalOp > _ -> helpScreen > > normalOp = do > ... > > helpScreen = putStrLn helpStr Code should be formatted in a way easy to scan and overview. You have to SEE the structure of the code. That depends very much on what your program does. No rules of thumb. Experience and experiments will do. (That was taken *directly* out of my convoluted brain and may be totally dumb.) Markus -- Markus Schnell Infineon Technologies AG, CPR ET Tel +49 (89) 234-20875 > -----Ursprüngliche Nachricht----- > Von: Per Larsson [mailto:per@L4i.se] > Gesendet: Dienstag, 26. August 2003 14:01 > An: haskell-cafe(a)haskell.org > Betreff: Haskell indentation > > > Hi, > > I have problems finding a pleasing indentation style for haskell code. > Especially nested do-blocks have a tendency to run away to > the right margin. > When looking on source code from experienced haskell > programmers, there > seems not to be any consensus at all, everyone uses their own > convention > and in many cases one changes style in the same module. > > Also, the automatic tools are problematic: the emacs mode I'm using > bails out in certain contexts and there are few user > customizations available. > The haskell-src module in the GHC library offers a parser > and pretty-printer for haskell code with nice options for customizing > the indentation, but it can't handle comments which is a problem if > you want to use it as a basis for implementing a indentation tool. > > Is there anyone who have given this some thought and have some > suggestions for a consistent indentation style and/or desktop tools > which I'm not aware of? > > Per > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Re: Homework
by oleg＠pobox.com 26 Aug '03

26 Aug '03

> Here's one: figure out what the following does :-) > puzzle = (!!) $ map (1:) $ iterate (s (lzw (+)) (1:)) [] where > s f g x = f x (g x) > lzw op xs [] = xs > lzw op [] ys = ys > lzw op (x:xs) (y:ys) = op x y : lzw op xs ys Can be written simpler puzzle = (!!) $ iterate (s (lzw (+)) (0:)) [1] where s f g x = f x (g x) lzw op [] ys = ys lzw op (x:xs) (y:ys) = op x y : lzw op xs ys Incidentally, a small change gives a different series: puzzle1 = (!!) $ iterate (s ((lzw (+)).(0:)) (1:)) [] where s f g x = f x (g x) lzw op [] ys = ys lzw op (x:xs) (y:ys) = op x y : lzw op xs ys can you tell which? Without loading into GHCi? Finally, how can we possibly live without the following: puzzle2 = (!!) $ iterate (s ((lzw (+)).(1:).(0:)) (0:)) [1,1] where s f g x = f x (g x) lzw op xs [] = [] lzw op (x:xs) (y:ys) = op x y : lzw op xs ys

1 0

IO Bool -> Bool
by Tn X-10n 24 Aug '03

24 Aug '03

6 5

recursion
by Tn X-10n 23 Aug '03

23 Aug '03

6 5

Numbers again
by Konrad Hinsen 22 Aug '03

22 Aug '03

I am getting a bit worried about the usability of Haskell for numerical work. The Haskell 98 report states that floating literals are represented as a conversion from Rational, which means that the literal is first converted to a Rational. I can't find anything in the Haskell report that states how this conversion should take place, and to what precision it should be correct. It could be made correct to any precision as Rationals are represented using Integers, but at least Hugs doesn't do that. By experimenting with some particular cases, I found that its internal Rational representation is even less accurate than the precision of Double permits, which means that it is impossible to specify literals to the full precision of Double. GHC behaved fine in my tests. But what can I safely assume from a Haskell implementation? Konrad.

2 1