- Haskell-Cafe - Haskell.org

homework help: upn parser
by Max Hoffmann 15 Dec '03

15 Dec '03

Dear Haskell cafe members, I am somebody one could well call a bloody beginner but the elegance of functional programming and am therefore truly interested to learn more about Haskell. Now I have an assignment to write a parsing function to convert a string of a mathematical expression into a tree in UPN style to evaluate it afterwards. So my evaluating function looks like this: data Op = Plus|Minus|Times|Div|Fac deriving(Show,Eq) data OpTree = Term OpTree Op OpTree |Number Float |E deriving(Show,Eq) eval(Number z) = z eval(Term li op re) |op == Plus= (eval li) + (eval re) |op == Minus= (eval li) - (eval re) |op == Times= (eval li) * (eval re) |op == Div= (eval li) / (eval re) And I tried to write a parsing function but I got stuck in the very beginning. So far I wrote: --parsing parsing :: String->[OpTree] parsing (a:b:c:xs) t |isDigit b = ((parsing xs)) ((Term (read a) c (read b)):t) And the Hugs compiler gives me so many error messages, that I have no clue how to get rid of this mess. Could anybody give me a hint where my error is and whether I am right in the general direction. Thanks a lot for any kind of help, Max Hoffmann

2 1

Re: homework help: upn parser
by Leon Smith 15 Dec '03

15 Dec '03

Hi Max! This is a type definiton, which says that parsing takes one argument, a String, and gives you back a list of OpTree: > parsing :: String->[OpTree] > This is a function definition. The part before the = is called the left hand side, while the part after the = is called the right hand side. > parsing (a:b:c:xs) t > |isDigit b = ((parsing xs)) ((Term (read a) c (read b)):t) > > The (a:b:c:xs) is an example of a pattern. You are using the list constructor (:) to break down the list into individual items. According to your type definition, this argument is of type String, which is the same thing as [Char]. Thus, a, b, and c are bound to single characters, while xs is the bound to the rest of the string, assuming your string has at least three characters. If your string has less than three characters, then this pattern fails and the next clause in your function definiton will be tried. Then, according to your function definition, you then bind the second argument of the function to the variable "t". However, your type definition says you only have one argument. Since they disagree, this is an error. The right hand side of your function definition contains lots of errors, as you suggest. You probably want to rethink your type definition. I'd suggest the following: parsing :: String -> [OpTree] -> OpTree This says that parsing is a function that takes two arguments, a list of characters and a list of OpTrees, and returns a single OpTree. You are going to treat the second list argument like a stack. When you run across a number in your string, you are going to take the number off the string and push it onto the stack. When you run across an operation in your string, you are going to take two elements off the stack, combine the elements from the stack using the operation, and push the result back on the stack. Thus, your solution would contain this kind of structure: parsing ( string_with_number_in_front ) ( stack ) = parsing ( string_without_number ) ( Number (the_number) : stack ) parsing ( string_with_operation_in_front ) (last_element : next_element : rest_stack) = parsing ( string_without_operation ) ( Term last_element (the_operation) next_element : rest_stack ) Now, you must consider the boundary cases of the function "parsing". What I mean is, what kinds of clauses do you need for when you are done with recursion, and what should your first call to this function look like? Of course, you need to try out your code and carefully think about what it's doing. When asking for homework help on haskell-cafe, Haskellers have been known to introduce small intentional errors into their advice. Also, it's very impressive that Paul Natorp high school is using Haskell in it's coursework! In the United States, I've never heard of a high school that takes functional programming seriously. Sadly, many American universities don't take functional programming seriously either. Americans are really behind the game in this regard. Hope this helps. best, leon

1 0

Preventing/handling space leaks
by Henk-Jan.van.Tuyl 13 Dec '03

13 Dec '03

L.S., Does anyone know about documentation (preferably on the Web) on how to prevent/find/remove space leaks? Are there any differences between Hugs and GHC or any other Haskell platform, regarding space leaks? I read some discussions about why not everybody uses Haskell; it looks to me, that the problem of space leaks is a very good reason to not use Haskell for commercial applications. Java, for example, does not have this problem. -- Best regards, Henk-Jan van Tuyl

10 17

Re: import modules from a different directory
by Georg Martius 11 Dec '03

11 Dec '03

<moved to haskell-cafe> Hi, You can give GHC with -iPath a directory where to look for modules. With -v you see where GHC actually looks for libraries. Cheers, Georg On Thu, 11 Dec 2003 15:59:04 +0800 (GMT-8), Wang Meng <wangmeng(a)comp.nus.edu.sg> wrote: > Hi All, > > Anybody has the experience of importing a module from a different > directory?In my code, i need to import a module that is not in the > current > directory. How can I do that in GHC? > > > -W-M- > @ @ > | > \_/ > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

type of (/) ?
by Yaroslav Korchevsky 10 Dec '03

10 Dec '03

I have been trying Hugs98 This is the average of floats list calculation program: ================================ accum :: [Float] -> Float accum list = foldr (+) 0 list my_avg list = (accum list) / (length list) ================================ While loading it I got the compiler message: ERROR "U:\slav\FP\Avg.hs":11 - Type error in application *** Expression : accum list / length list *** Term : accum list *** Type : Float *** Does not match : Int Why "accum list" should match to "Int"? When I try to replace (length list) with number - it works. ================================ my_avg list = (accum list) / 5 --works fine ================================ xx = 5 my_avg list = (accum list) / xx --doesn't work -- same message as above ================================ Possibly, I don't know something important, or Hugs is not quite mature? Thank you. Slav.

4 3

Re: Multiple functions applied to a single value
by Graham Klyne 10 Dec '03

10 Dec '03

A little while ago, I sent a long rambling message [1] containing a key question in response to an earlier helpful response. I guess my ramblings were quite reasonably passed over as too much waffle, and the question was lost. Here, I isolate the question. From the earlier response, I understand that: ((->) r) is an instance of Monad, but I haven't found a definition of the Monad instance functions. I think these do the job, and they satisfy the monad laws [2]: [[ instance Monad ((->) r) where return a = const a g1 >>= f = \e -> f (g1 e) e ]] Can anyone confirm, or point me at an actual definition? #g -- [1] http://haskell.org/pipermail/haskell-cafe/2003-November/005566.html [2] Checking the Monad laws for the above definitions (cf. Haskell report p90): (A) return a >>= k = [g1/const a][f/k] \e -> f (g1 e) e = \e -> k (const a e) e = \e -> k a e = k a -- as required. (B) m >>= return = [g1/m][f/const] \e -> f (g1 e) e = \e -> const (m e) e = \e -> (m e) = m -- as required. (C) m >>= (\x -> k x >>= h) = [g1/m][f/(\x -> k x >>= h)] \e -> f (g1 e) e = \e -> (\x -> k x >>= h) (m e) e = \e -> (k (m e) >>= h) e = \e -> ([g1/k (m e)][f/h] \e1 -> f (g1 e1) e1) e = \e -> (\e1 -> h (k (m e) e1) e1) e = \e -> h (k (m e) e) e (m >>= k) >>= h = ([g1/m][f/k] \e -> f (g1 e) e) >>= h = (\e -> k (m e) e) >>= h = [g1/(\e -> k (m e) e)][f/h] \e1 -> f (g1 e1) e1 = \e1 -> h ((\e -> k (m e) e) e1) e1 = \e1 -> h (k (m e1) e1) e1 = \e -> h (k (m e) e) e So both expressions are equivalent, as required. ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

3 2

RE: Common subexpressions are not optimized to single one?
by Simon Marlow 09 Dec '03

09 Dec '03

> I'm wondering about the optimization of ghc. I thought that since > functions are pure in haskell, compiler can/do factorize common > subexpressions when it optimizes a code. But the result of > the following > experiment looks negative; "g 10 100" is caluculated twice. > > Am I missing something? If not, > What prevents ghc from performing that optimization? > Should I always factorize common subexpressions > manually(using let or where)? GHC *does* do common sub-expression elimination. However it only considers simple applicative subexpressions as candidates for commoning up, and in your example it turns out that by the time the CSE pass runs, various inlinings and transformations have happened which means that the candidate expressions are quite large. Perhaps we could run the CSE pass at an earlier stage, or perhaps it should run twice - that's one of those tradeoffs between compilation time and runtime. Perhaps the extra pass should be done for -O2 only. We'll look into it. Thanks for the example, anyhow. Cheers, Simon

1 0

Infinite types
by Jeffrey A. Scofield 09 Dec '03

09 Dec '03

Greetings. Say I have the following function, adapted from Pierce, Types and Programming languages: f n () = (n, f (n + 1)) Now, this function fails to typecheck in ghc 6.0.1 because the subexpression f (n + 1) has the infinite type t = () -> (t1, t) And so I assume (perhaps wrongly?) that f is ill-typed in Haskell 98. I have two questions: 1. How can I tell from the Haskell 98 Revised Report that this function isn't allowed? The discussions of typing in the Report generally defer to the ``standard Hindley-Milner analysis.'' Is this really enough to tell that the function isn't well-typed in Haskell? I concede that I haven't read the cited Hindley and Damas/Milner papers, but it seems like there might be more to say about what is and isn't allowed. 2. Is there by chance a compiler option for ghc that causes the restriction to be dropped? I don't need this kind of function for anything practical (and I realize I can get an equivalent effect with an algebraic datatype). I'm just trying to figure out what typing restrictions (if any) are implicitly assumed in the Report. (Generally, this is the kind of stuff I don't know, as a relative newcomer to fp.) Regards, Jeff Scofield (PhD) Seattle

6 9

Re: Infinite types
by jeff＠dhitechnologies.com 07 Dec '03

07 Dec '03

Alastair Reid wrote: > > 1. How can I tell from the Haskell 98 Revised Report that [a function > > with an infinite type] > > isn't allowed? The discussions of typing in the Report > > generally defer to the ``standard Hindley-Milner analysis.'' > 1) The only way to write the recursive type you want > in Haskell is using type synonyms. > 2) The section describing type synonyms (4.2.2) explicitly rules it out. This really makes sense, but I had been interpreting 4.2.2 as a limitation on type synonym declarations rather than on types themselves. It says: Although recursive and mutually recursive datatypes are allowed, this is not so for type synonyms, unless an algebraic datatype intervenes. To my (untutored) eye, this looks like a limitation on what can appear in a type synonym declaration, not a limit on what types can appear in a program. Is it a reliable mental model to assume that if there's no way to declare a type in Haskell, the type itself isn't allowed in a program? (Note that this can't be true in every case; according to 4.5.4, the monomorphism restriction introduces types that can't be declared in Haskell.) Thanks very much for the response. Regards, Jeff Scofield Seattle

1 0

Common subexpressions are not optimized to single one?
by Koji Nakahara 03 Dec '03

03 Dec '03

Hi, I'm wondering about the optimization of ghc. I thought that since functions are pure in haskell, compiler can/do factorize common subexpressions when it optimizes a code. But the result of the following experiment looks negative; "g 10 100" is caluculated twice. Am I missing something? If not, What prevents ghc from performing that optimization? Should I always factorize common subexpressions manually(using let or where)? --- $ cat op.hs module Main where import System.IO.Unsafe foreign import ccall "count" io_count:: IO Int f :: Int -> IO Int f x = do {y <- io_count; return $ x + y} g :: Int -> Int -> Int g x y = unsafePerformIO $ do {z <- f x; return $ z + y} main = do print (g 10 100, g 10 100) $ $ cat ffi_test_c.c static int counter = 0; int count() {return counter++;} $ $ gcc -c ffi_test_c.c;ghc -O2 -ffi op.hs;ghc -o op_test op.hs ffi_test_c.o $ ./op_test (110,111) --- I want to use some C functions from haskell each of which is not pure but the result of their sequential combination is pure. I'm planning to write some functions like g above(but more complex and actually pure) and considering the optimization of the code using them. Thanks in advance. Koji Nakahara

3 3