- Haskell-Cafe - Haskell.org

HWS - With Plugins
by Johan Tibell 09 Aug '06

09 Aug '06

The HWS - With Plugins tarball is unavailable at the author's website (http://www.mdstud.chalmers.se/~md9ms/hws-wp/) and his email address doesn't work so this is desperate attempt to reach him. So, Martin Sjögren, are you here somewhere? P.S. If someone else knows where I could get hold of the source or at least the source of the original HWS I would be greatful. Cheers, Johan

2 1

Abstract Data Types
by Johan Grönqvist 09 Aug '06

09 Aug '06

Hi, I have a question: Short version: If I want to hide the implementation of a data-type "Stack a" from the rest of the program, do I need to put its definition in a separate file? Long version: I want to use a stack, and I might implement it as a list, but I want to hide the implementation from the rest of the program. This is how I understand abstract data type. In "The Craft of Functional Programming", this seems to be implemented by putting each data type into a separate module and only exporting parts of the definitions. In "The Haskell School of Expression", this seems not to be used at all. In the lecture notes at (http://www.dcs.shef.ac.uk/~mps/courses/com2020/adts.pdf) type classes are used for abstract data types. It seems to me that this approach does not hide any parts of any definition, but only requires that all instances of class stack have functions pop and push of the correct types. I am interested in hiding parts of definitions. In the report, I did not find any mention of a requirement to have different modules in separate files, but I have not managed to put several modules in the same file using ghci. I would like to keep my small program in one literate-haskell tex-file and still be able to hide some definitions from others. Is this possible? One option would of course be to write a script that separates the code into different and then compiles the entire program. Thanks in advance! / johan grönqvist

2 1

AJAX applications in Haskell
by tittoassini＠gmail.com 09 Aug '06

09 Aug '06

Hi, Those among you who have an interest in AJAX-style web development - that is to say the development of web applications that run entirely into the browser environment, calling back to the server back-end only to get raw data -- will probably have noticed the recent appearance of the Google Web Toolkit (http://code.google.com/webtoolkit) The main idea behind it is very simple: you write your Ajax application in Java and your code is compiled down to JavaScript/HTML (rather then to Java Virtual Machine bytecode) so that it can be executed in any browser. The main advantages of this solution are: - Development using a typed language with good compile-time checks and debugger support - No plugins (e.g. a Java VM) required on the user machine The disadvantages are: - An additional compilation step - Probably, a significant loss of performance with respect to hand-written code Assuming that the balance is positive, this naturally raises the question: why not doing the same with our favourite language? This would require to: - Retarget one of the existing Haskell compilers to generate JavaScript (other possible targets would be Flash or higher level UI languages such as OpenLaszlo that in turn compiles down to either Flash or JavaScript/HTML) - Write a suitable runtime library (including support for native JavaScript or Flash UI components, remote method invocations, multi-threading, etc.) - Port a usable subset of the Haskell Libraries - Select an approach to write user interfaces in Haskell. There have been many attempts in this direction but I am unsure if any of them has proven particularly successful. All considered, quite a significant amount of work -- that would require a concerted group effort -- with a rather uncertain pay-off. Is anyone working on anything similar or that might be interested in such a project? And has anyone any thoughts to offer on what compilers/libraries/UI frameworks would be more suitable for the task? Regards, titto assini

1 0

Re: [Haskell-cafe] creating tree with level subnodes and incrementing number?
by Marc Weber 09 Aug '06

09 Aug '06

Thanks to you all! I think I've learned a lot. Marc

1 0

IO Monad/ haskelldb strange error?
by Marc Weber 09 Aug '06

09 Aug '06

line << 39 works fine line 56 doesn't. Why? Isn't both a IO monad (because of the print statements) After commenting out 56 it compiles fine Any suggestion appreciated.. I'm struggling for some hours now.. module Modules.ObjectTree where import Debug.Trace import Data.FunctorM import DBUtils import qualified DB.VT.Ezcontentobject_tree as EOT import qualified DB.VT.Ezcontentobject as CO import Database.HaskellDB.HDBRec import Database.HaskellDB import Database.HaskellDB.Query as Q import Data.Tree import Monad import Control.Monad.Trans import Maybe import qualified List instance FunctorM Tree where fmapM f (Node a forest) = do a' <- f a forest' <- mapM (fmapM f) forest return $ Node a' forest' type ObjectTree a = Tree (Record a) truncTree 1 (Node a _) = Node a [] truncTree x (Node a forest) = Node a $ map (truncTree (x-1)) forest oT con = do print "blah" -- because of this we should have a simple IO Monad ? lookupField con (CO.name) (CO.ezcontentobject) (CO.xid) (constant (1 :: Int)) >>= print :: IO () -- <<<<<<<<<<<<<<<<<<<<<<<<< 39 return "blah" -- printObjectsAsTree :: MonadIO m => ((Database -> m a) -> m a) -> Int -> IO () printObjectsAsTree con startid= do print "test" root <- liftM head $ lRS (EOT.parent_node_id) (constant (startid :: Int)) print root --showRS root >>= putStrLn node <- po root node_show <- fmapM showRS node return $ drawTree node_show -- return "end" where lRS = lookupFieldRS con (EOT.ezcontentobject_tree) po root = let root_id = (root!(EOT.node_id) :: Int) in do print "dumm" -- IO Monad too ? print (root!(EOT.node_id)) lookupField con (CO.name) (CO.ezcontentobject) (CO.xid) (constant (1 :: Int)) >>= print -- <<<<<<<<<<<<<< 56 return $ Node root [] --childs <- lRS (EOT.parent_node_id) (constant root_id) --mapM_ (\r -> r!(EOT.node_id)) childs >>= print showRS r = do -- name <- lookupField con (CO.name) (CO.ezcontentobject) (CO.xid) (constant 1) >>= print return "ab" :: IO String --return $ (show $ r!node_id) ++ " (" ++ (fromJust name) ++ " )" ----------------------------------------------- || Preprocessing executables for dbez-0.0... || Building dbez-0.0... || Chasing modules from: db_ez.hs || [1 of 6] Skipping DBUtils ( DBUtils.hs, dist/build/db_ez/db_ez-tmp/DBUtils.o ) || [2 of 6] Skipping DB.VT.Ezcontentobject_tree ( DB/VT/Ezcontentobject_tree.hs, dist/build/db_ez/db_ez-tmp/DB/VT/Ezcontentobject_tree.o ) || [3 of 6] Skipping DB.VT.Ezcontentobject ( DB/VT/Ezcontentobject.hs, dist/build/db_ez/db_ez-tmp/DB/VT/Ezcontentobject.o ) || [4 of 6] Compiling Modules.ObjectTree ( Modules/ObjectTree.hs, dist/build/db_ez/db_ez-tmp/Modules/ObjectTree.o ) || Modules/ObjectTree.hs|43| 0: || Couldn't match `DB.VT.Ezcontentobject_tree.Contentobject_id' || against `DB.VT.Ezcontentobject.Contentclass_id' || Expected type: RecCons DB.VT.Ezcontentobject_tree.Contentobject_id || (Maybe Int) || vr || Inferred type: RecCons DB.VT.Ezcontentobject.Contentclass_id || Int || vr1 || When using functional dependencies to combine || Database.HaskellDB.Database.GetRec (RecCons f (Expr a) er) || (RecCons f a vr), || arising from the instance declaration at Imported from Database.HaskellDB.Database || Database.HaskellDB.Database.GetRec (RecCons DB.VT.Ezcontentobject_tree.Contentobject_id || (Expr (Maybe Int)) [...] || (RecCons DB.VT.Ezcontentobject_tree.Sort_order || (Expr (Maybe Int)) || RecNil)))))))))))))))) || (RecCons DB.VT.Ezcontentobject.Contentclass_id Int vr), arising from use of `lookupFieldRS' at Modules/ObjectTree.hs|52| 14-26 || When generalising the type(s) for `printObjectsAsTree'

4 4

RE: [Haskell] thread-local variables
by Simon Peyton-Jones 09 Aug '06

09 Aug '06

| I have initialized a wiki page: | | http://haskell.org/haskellwiki/Thread_local_storage Great | I have put a page on the wiki summarizing the thread. However, I want | to say that I think that email is a better medium for most ongoing | discussions. I agree. Discussion by email Outcomes on Wiki (including outcomes recording differences of viewpoint) The goal is that the outcome is a comprehensible summary of the outcome of the discussion, for the benefit of the many who will not follow the evolving debate. Furthermore, can we move this thread from the Haskell mailing list (which should not have heavy traffic) to either Haskell-Café, or the libraries list? Simon

2 1

How can we detect and fix memory leak due to lazyness?
by Ahn, Ki Yung 08 Aug '06

08 Aug '06

Recently, I'm facing the dark side of laziness -- the memory leak because of laziness. Typical pattern that I encounter the problem is like this. My code was working fine and I was happy. I just wanted to inspect some properties of my code so I made a slight chage go the code such as adding counter argument or attaching auxiliary data filed to original data for tracing how the data has been constructed. All of a sudden the program runs out of memory or overflows the stack. One problem is that it comes up unexpectedly. Another even worse problem is that sometimes I get no idea for the exact location causing the leak! It really panics facing such darkness of lazy evaluation. Just a small innocent looking fix for inspection or tracing blow things up, sometime with no clue for its reason. When we implement a debugging or tracing option in the software and let the user toggle those features, how could we be sure that turning on those features won't crash the software written in Haskell? Are there standardized approaches for detecting and fixing these kind of problems? Haskell may be type safe but not safe at all from unexpanded diversion, which is not because of the programmers' mistake but just because of the laziness. I have posted an wiki article including one example of adding a counter to count the number of basic operations in sorting algorithm. http://www.haskell.org/haskellwiki/Physical_equality This was a rather simple situation and we figured out how to cure this by self equality check ( x==x ) forcing evaluation. There are worse cases not being able to figure out the cure. I wrote a function for analyzing some property of a graph, which worked fine. fixOnBy t p f x = if t x' `p` t x then x else fixOnBy t p f x' where x' = f x fixSize f x = fixOnBy Set.size (==) f x sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [(x,y,cs) | To _ x y cs<-Set.toList gs] cgs = [z | z@(x,y,cs)<-Set.toList gs', x==y] dcs = [ [c| c@(a,D,b)<-Set.toList cs , a==b] | (_,_,cs)<-cgs] compose gs = trace ("## "++show (Set.size gs)) $ foldr Set.insert gs $ do (x1,y1,cs1) <- Set.toList gs (_,y2,cs2) <- takeWhileFst y1 $ Set.toList $ setGT (y1,Al""(-1),Set.empty) gs return (x1,y2,cs1 `comp` cs2) takeWhileFst y = takeWhile (\(y',_,_) -> y==y') This function makes a transitive closure of the given set of relations by fixpoint iteration on the size of the set of weighted edges. Sample output is like this. *Main> main ## 170 ## 400 ## 1167 ## 2249 ## 2314 False When I add an extra data field for tracing how the new relation was constructed, (e.g. tag [a,b,c] on a->c if it came from a->b and b->c) it suddenly overflows the stack even before printing out the trace. The following is the code that leaks memory. sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [TT (x,y,cs) [] | To _ x y cs<-Set.toList gs] cgs = [z | z@(TT (x,y,cs) _)<-Set.toList gs', x==y] dcs = [[c| c@(a,D,b)<-Set.toList cs , a==b] | TT (_,_,cs) _<-cgs] compose gs = trace ("## "++show (Set.size gs)) $ foldr checkInsert gs $ do TT (x1,y1,cs1) l1 <- Set.toList gs TT (_,y2,cs2) l2 <- takeWhileTTfrom y1 . Set.toList $ setGT (TT (y1,Al""(-1),Set.empty) []) gs return $ TT (x1,y2,cs1 `comp` cs2) (l1++y1:l2) takeWhileTTfrom y = takeWhile (\(TT (y',_,_) _) -> y==y') checkInsert x s | Set.member x s = s | otherwise = Set.insert x s data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) => Eq (TT a b) where (TT x lx) == (TT y ly) = lx==lx && ly==ly && x == y instance (Ord a, Ord b) => Ord (TT a b) where (TT x lx) < (TT y ly) = lx==lx && ly==ly && x < y The really intersting thing happens when I just make the Ord derived the stack does not overflow and starts to print out the trace. (It is not the result that I want though. My intention is to ignore the tags in the set operation) data TT a b = TT a b deriving (Show,Eq,Ord) I believe my Eq and Ord instances defined above are even more stricter than the derived ones. Is there some magic in "deriving" that prevents memory leak? I've even followed the instance declaration like the following that would be the same as deriving but still leaks memory. data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) => Eq (TT a b) where (TT x lx) == (TT y ly) = x == y && lx == ly instance (Ord a, Ord b) => Ord (TT a b) where (TT x lx) < (TT y ly) = x < y || x == y && lx < ly This is really a panic. -- Ahn, Ki Yung

8 8

Re:Re: Why Haskell
by Hans van Thiel 08 Aug '06

08 Aug '06

From: Hans van Thiel <hthiel.char(a)zonnet.nl> Reply-To: hthiel.char(a)zonnet.nl To: Johan Tibell <johan.tibell(a)gmail.com> Subject: Re: [Haskell-cafe] Re: Why Haskell? Date: Mon, 07 Aug 2006 17:21:17 +0200 On Mon, 2006-08-07 at 15:23 +0200, Johan Tibell wrote: > For me library support, for networking in particular, has been the > major hurdle. It gets problematic when too many libraries are still > marked as experimental and only partially implements the specification > (e.g. protocol) that they are supposed to handle. Also after a quick > look at the source for some common (networking) libraries I found a > few too many calls to error to feel comfortable. It's not okay for a > library to bring down my application behind my back, error should be > reported even if this uglifies the code and interfaces. Furthermore I > think that Haskell would benefit from moving some commonly used > functionality such as HTTP, SQL and XML support into the standard > libraries. I haven't seen any news about the progress of HaskellNet > but I guess it could solve my problems. > That's good to know, thanks! > I really don't have much problems with tool support, speed and the > like. I'm convinced it's a library (and library documentation!) thing. > Likewise. > > > Having someone pay a group of people to hack on Haskell > implementations would indeed be desirable. Without knowing the details > Ubuntu looks like a promising model. If we could just find a willing > billionaire out there.. Candidates would be companies that have an interest in promoting Haskell and/or fp, large and small. Ericsson comes to mind, if they are still active in fp. Or maybe one of the rising Indian, Chinese or or other 'globalization' firms could be the principal here? Personally, I'd love to see a Brazilian company like, for example, PetroBras pick this up. And just from a PR point of view, Haskell does project a cutting edge image. Anyway... Regards, Hans > Cheers, > > Johan

2 1

Need a good book on Haskell
by Johan Tibell 08 Aug '06

08 Aug '06

I've read Haskell: The Craft of Functional Programming on a course on functional programming at Chalmers (I also took the advanced course) and now I'm looking for some more reading material. Are there any other good Haskell books? Is there a Pick Axe, Camel or Dragon Book for Haskell?

3 2

The dark side of lazyness - memory leak
by Ahn, Ki Yung 08 Aug '06

08 Aug '06

I'm facing the dark side of lazyness recently. Typical pattern is like this. My code was working fine and I was happy. I just wanted to inspect some properties of my code so I made a slight chane go the code such as adding counter argument or attaching axulary data filed to original data for tracing how the data has been constructed. All of a sudden the program runs out of memory or overflows the stack. One problem is that it comes up unexptectedly. Another even worse problem is that sometimes I get no idea for the exact loation causing the leak! It really panics facing such darkness of lazy evaluation. Just a small innocent looking fix for inspection or tracing blow things up, sometime with no clue for its reason. When I put a debugging or tracing operating in my software that can be toggled, how could I be sure that turning on those features won't crash my software written in Haskell? Are there appraoches to detect and fix these kind of problem? Haskell may be type safe but not safe at all from unexpteded diversion, not because of the programmers' mistake but just because of the lazyness. I have posted an wiki article including one example of this dark side of lazyness I encountered when I tried to count the number of basic operations in sorting algorithm. This was a rather simple situation and we figured out how to cure this by self equality check ( x==x ) forcing evaluation. There are wose cases not being able to figure out the cure. I wrote a fucntion for analyzing some property of a graph, which worked fine. fixOnBy t p f x = if t x' `p` t x then x else fixOnBy t p f x' where x' = f x fixSize f x = fixOnBy Set.size (==) f x sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [(x,y,cs) | To _ x y cs<-Set.toList gs] cgs = [z | z@(x,y,cs)<-Set.toList gs', x==y] dcs = [ [c| c@(a,D,b)<-Set.toList cs , a==b] | (_,_,cs)<-cgs] compose gs = trace ("## "++show (Set.size gs)) $ foldr Set.insert gs $ do (x1,y1,cs1) <- Set.toList gs (_,y2,cs2) <- takeWhileFst y1 $ Set.toList $ setGT (y1,Al""(-1),Set.empty) gs return (x1,y2,cs1 `comp` cs2) takeWhileFst y = takeWhile (\(y',_,_) -> y==y') This fucntion makes a transitive closure of the given set of relations by fixpoint iteration on the size of the set of weighted edegs. Sample output is like this. *Main> main ## 170 ## 400 ## 1167 ## 2249 ## 2314 False When I add an extra data field for tracing how the new item was made (e.g. tag [a,b,c] on a->c if it was generated by a->b and b->c) It suddenly overflows the stack even before printing out the trace. The following is the code that leaks memory. sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [TT (x,y,cs) [] | To _ x y cs<-Set.toList gs] cgs = [z | z@(TT (x,y,cs) _)<-Set.toList gs', x==y] dcs = [[c| c@(a,D,b)<-Set.toList cs , a==b] | TT (_,_,cs) _<-cgs] compose gs = trace ("## "++show (Set.size gs)) $ foldr checkInsert gs $ do TT (x1,y1,cs1) l1 <- Set.toList gs TT (_,y2,cs2) l2 <- takeWhileTTfrom y1 . Set.toList $ setGT (TT (y1,Al""(-1),Set.empty) []) gs return $ TT (x1,y2,cs1 `comp` cs2) (l1++y1:l2) takeWhileTTfrom y = takeWhile (\(TT (y',_,_) _) -> y==y') checkInsert x s | Set.member x s = s | otherwise = Set.insert x s data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) => Eq (TT a b) where (TT x lx) == (TT y ly) = lx==lx && ly==ly && x == y instance (Ord a, Ord b) => Ord (TT a b) where (TT x lx) < (TT y ly) = lx==lx && ly==ly && x < y The really intersting thing happens when I just make the Ord derived the stack does not overflow and starts to print out the trace. (It is not the result that I want though. My intention is to ignore the tags in the set operation) data TT a b = TT a b deriving (Show,Eq,Ord) I believe my Eq and Ord instances are even more stricter than the derived ones. Is there some magic in "deriving" that prevents memory leak? I've even followed the instance declaration that would be the same as deriving but the that leaks memory. data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) => Eq (TT a b) where (TT x lx) == (TT y ly) = x == y && lx == ly instance (Ord a, Ord b) => Ord (TT a b) where (TT x lx) < (TT y ly) = x < y || x == y && lx < ly This is really a panic. -- Ahn, Ki Yung

1 0