Python & Haskell
Has anybody on the list used Haskell and python together such that the haskell data-types appear to be native Python objects? I'm currently developing a debugger which uses Haskell engines for the algorithmic parts, but I'm finding Python to be a flexible glue language, which my users could more easily adapt to than Haskell. Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Persistent data
Is there some way to reduce the cost of garbage collection over large persistent datastructures without resorting to escaping to C to malloc memory outside the heap? The program I'm working is part database, which cannot discard information. The net result is that I see figures like 82.9% of the time taken by garbage collection. The heap profile looks like a charging capacitor: a linear increase (as expected) which is slowly dilated as time increases by the garbage collector thrashing memory. When I worked on the LOLITA natural language processor we solved the problem by moving a lot of the data out to C++, so that the heap only contains things soon to be freed. I know generational garbage collection is supposed to help, but it doesn't seem to. Is there a pure Haskell solution to this problem? Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Balanced ternary tree
I was wondering if anyone has implemented a Balanced Ternary Tree module for haskell. According to http://www.ddj.com/documents/s=921/ddj9804a/9804a.htm this would be a better datastructure for symbol tables than the binary tree I am currently using: * Each string is a key, which makes for O(n/2 * log m) comparisons where n is the average string length and m is the number of string in the table, * A balanced ternary tree would be O(n + log m). (DDJ's code does not balance the tree) Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Lazy IO?
On Tue, 3 Sep 2002 20:08:32 +0100 "Duncan Coutts" <[EMAIL PROTECTED]> wrote: > On Tue, 3 Sep 2002 14:49:45 -0400 > [EMAIL PROTECTED] wrote: > > > Is there any way to make the IO Monad lazy? > > > > The simplified version of my problem is that I want to > > generate an infinite structure from an IOArray and then > > consume only the relevant part of it. > > Yes, unsafeInterleaveIO. > > >http://www.haskell.org/ghc/docs/latest/html/base/System.IO.Unsafe.html#unsafeInterleaveIO > > This is how getContents is implemented so that it reads the file lazily. > > Be careful of course it is "unsafe". > > Duncan Excellent. Thanks a lot, Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Lazy IO?
Is there any way to make the IO Monad lazy? The simplified version of my problem is that I want to generate an infinite structure from an IOArray and then consume only the relevant part of it. The real version of my problem is that the IOArray is embedded 4 API layers deep and it would be a lot of effort to change all those APIs and dependent code for this 1 change. Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell slicing tool?
On Tue, 19 Mar 2002 09:56:49 + "Colin Runciman" <[EMAIL PROTECTED]> wrote: > > Are there any tools to perform program slicing on Haskell? > > I often find myself wanting to find all "fromJusts" invoked > > from the current function, or all functions that use a > > particular member of my monad's ADT. > > Assuming that what you want to see are the applications of > these functions that occur at run-time, and the evaluation > contexts in which they arise, you could try the Hat > tracing tools (http://www.cs.york.ac.uk/fp/hat/). Actually I was hoping for a static tool. But now HAT works with GHC I'll be trying it out. Thanks. Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Haskell Programming Environment
> Hello, > > I'm writing my master thesis. Its subject is 'Haskell Programming > Environment'. It is (or rather will be) an extended text editor working i= > n > graphical (XFree86) environment designed for Haskell programmers. It will= > be > implemented using Fudgets library. > I'm wondering what features would you like to find in such environment. W= > hat > should be neccessary, what would help, what would make writing programs > easier, etc. > I have some concepts, but I would like to hear some suggestions from you. > > Thanks for all answers. a) the ablility to highlight an area of code and get its type (be it a function, or some well-formed chunk of code b) the ability to highlight a function and get its definition in another area (think multiple text editing in vim) c) interaction with hugs/stg-hugs so that just written code can be pasted into a "hugs window" for evaluation. d) Debug mode which automatically adds "deriving show" to all datatypes which are not showable/adds exporting of all Datatypes as non-abstract for use in hugs to just allow things to be tried out. e) Debug mode which invisibly replaces functions such as "fromJust" with error making versions (... fromJust' "the file and line at which I'm invoked" ...) to make it easier to find the cause of the error (fromJust Nothing just comes up with an error telling you that it's fromJust that failed. Last time that happened, I hacked hugs to dump the evaluation stack, from which I guessed which possible fromJusts it could have been). f) Use ghc's .hi file to allow strictness of arguments to appear if you leave the mouse over an argument. g) For bonus points (harder, but really useful when stuck): given an expression, show me (possibly using daVinci) how it gets evaluated: Lazyness behaviour is not always obvious, I'd like to see it. I've been wanting to code one of these myself, but have had no time. Try and see if stg-hugs is useable yet since that would be a much better environment to do it in. Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: mapM/concatMapMy
Actually I think I figured it out: (>>=) (f c) (\x -> (>>=) (mapM f cs) (\xs -> return (x:xs))) -> (>>=) _(f c)_ (\x -> (>>=) (mapM f cs) (\xs -> return (x:xs))) -> (>>=) (MN c1) (\x -> (>>=) (mapM f cs) (\xs -> return (x:xs))) -> (\(MN c1) \fc2 -> MN $ \s0 -> let (r1,io1,s1) = c1 s0 ( MN c2 ) = fc2 r1 (r2,io2,s2) = c2 s1 in (r2,io1 >> io2,s2)) (MN c1) (\x -> (>>=) (mapM f cs) (\xs -> return (x:xs))) -> (MN $ \s0 -> let (r1,io1,s1) = c1 s0 ( MN c2 ) = (\x -> (>>=) (mapM f cs) (\xs -> return (x:xs))) r1 (r2,io2,s2) = c2 s1 in (r2,io1 >> io2,s2)) -> (MN $ \s0 -> let (r1,io1,s1) = c1 s0 ( MN c2 ) = (>>=) (mapM f cs) (\xs -> return (r1:xs)) (r2,io2,s2) = c2 s1 in (r2,io1 >> io2,s2)) -> (MN $ \s0 -> let (r1,io1,s1) = c1 s0 ( MN c2 ) = (>>=) (mapM f cs) (\xs -> return (r1:xs)) (r2,io2,s2) = c2 s1 in (r2,io1 >> io2,s2)) -> (MN $ \s0 -> let (r1,io1,s1) = c1 s0 ( MN c2 ) = (>>=) (mapM f cs) (\xs -> return (r1:xs)) (r2,io2,s2) = c2 s1 in (r2,io1 >> io2,s2)) So the "return (r1:xs)" will only happen once the whole mapM has completed, leaving, if I only use r1 at first, a whole load of partially evaluated iterations of mapM in the heap. This also means that sequences such as "mapM x >>= mapM y >>= mapM z" are very inefficient and should be replaced by mapM (z.y.x) whereever possible. Agreed? Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: mapM/concatMapMy
> > [EMAIL PROTECTED] (Sengan Baring-Gould) wrote: > > > > > mapM seems to be a memory hog (and thus also concatMapM). > > > In the following eg: > > > > > > > main = mapM print ([1..102400] :: [Integer]) > > > > > > memory usage climbs to 1.6M with ghc and needs -K20M > > > > As a guess: since 'mapM print ([1..102400] :: [Integer])' > > has type 'IO [()]', perhaps the result of the IO operation -- > > a list of 100K empty tuples -- is the culprit, even though > > the result is never used. > > > > Does 'mapM_ print ... ' (:: IO ()) perform any better? > > Yes, but in the following eg > > > main = print $ sum x > > x = _scc_ "x" [1..102400] :: [Integer] > > x takes 1M allocations, and I would think that () would be smaller than > an Integer. Therefore I'm not sure that is the reason. The sum is there to > force the evaluation. Assuming you are right, why do I see the same 1.6M profile with: > main = mapM2 (_scc_ "p" (\x -> print x)) ([1..102400] :: [Integer]) >> return () > mapM2 :: Monad m => (a -> m b) -> [a] -> m [b] > mapM2 f [] = return [] > mapM2 f (c:cs) = _scc_ "a" (>>=) (_scc_ "d" f c) (\x -> > _scc_ "b" (>>=) (_scc_ "e" mapM2 f cs) (\xs -> > _scc_ "f" return (x:xs))) Is >>= not lazy? Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: mapM/concatMapMy
> > > [EMAIL PROTECTED] (Sengan Baring-Gould) wrote: > > > mapM seems to be a memory hog (and thus also concatMapM). > > In the following eg: > > > > > main = mapM print ([1..102400] :: [Integer]) > > > > memory usage climbs to 1.6M with ghc and needs -K20M > > As a guess: since 'mapM print ([1..102400] :: [Integer])' > has type 'IO [()]', perhaps the result of the IO operation -- > a list of 100K empty tuples -- is the culprit, even though > the result is never used. > > Does 'mapM_ print ... ' (:: IO ()) perform any better? Yes, but in the following eg > main = print $ sum x > x = _scc_ "x" [1..102400] :: [Integer] x takes 1M allocations, and I would think that () would be smaller than an Integer. Therefore I'm not sure that is the reason. The sum is there to force the evaluation. Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
mapM/concatMapM
mapM seems to be a memory hog (and thus also concatMapM). In the following eg: > main = mapM print ([1..102400] :: [Integer]) memory usage climbs to 1.6M with ghc and needs -K20M, whereas with > main = print ([1..102400] :: [Integer]) memory usage is only 1300 bytes. I instrumented mapM: > main = mapM2 (_scc_ "p" (\x -> print x)) ([1..102400] :: [Integer]) > mapM2 :: Monad m => (a -> m b) -> [a] -> m [b] > mapM2 f [] = return [] > mapM2 f (c:cs) = _scc_ "a" (>>=) (_scc_ "d" f c) (\x -> > _scc_ "b" (>>=) (_scc_ "e" mapM2 f cs) (\xs -> > _scc_ "f" return (x:xs))) and found that a and b were the worst heap users (according to hp2ps), ie the two >>='s Why is this so? What can I do about it? My code uses mapM pretty extensively, and I think its suffering from this problem. I notice that ghc does not seem to use mapM except in 2 modules. Another odd thing is that hp2ps says that a & b are the culprits, but the -p and -px options say p is. Why? Sengan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
