- Haskell-Cafe - Haskell.org

Doing exercises from "Haskell tutorial" ...
by Dmitry Astapov 02 Oct '01

02 Oct '01

It seems like an appropriate page for aske newbie questions, isnt it? I was reading through Haskell tutroial (http://www.di.uminho.pt/afp98/PAPERS/Tutorial.ps) and trying to do exercises from there. I'm stuck in the first exercise for "Classes" chapter (page 11). I need to define SetsAsLists as an instance of Set by supplying definitions for all Set methods, but definitions I wrote led me to adding additional constraints on "union" and "memeber" methods. Is it ok or it's possible to define "union" and "member" without using "==" ? Code follows: class Set s where empty :: s a isEmpty :: s a -> Bool singleton :: a -> s a union :: Eq a => s a -> s a -> s a member :: Eq a => a -> s a -> Bool choice :: s a -> (a, s a) data SetsAsLists a = SL [a] instance Set SetsAsLists where empty = SL [] isEmpty (SL []) = True isEmpty _ = False singleton x = SL [x] member x (SL ys) | isEmpty (SL ys) = False | otherwise = if x==head ys then True else member x (SL (tail ys)) union (SL []) (SL ys) = SL ys union (SL (x:xs)) (SL ys) | member x (SL ys) = union (SL xs) (SL (x:ys)) | otherwise = union (SL xs) (SL ys) -- Dmitry Astapov //ADEpt E-mail: adept(a)umc.com.ua GPG KeyID/fprint: F5D7639D/CA36 E6C4 815D 434D 0498 2B08 7867 4860 F5D7 639D

2 2

update in-place
by Cagdas Ozgenc 02 Oct '01

02 Oct '01

> data Foo = Foo { a :: Int, b :: String } > > instance Show Foo where > show f = show (a f) ++ " " ++ show (b f) > > foo = Foo { a = 99, b = "green bottles\n" } > > main = do print foo > let bar = foo { a = 98 } > print bar The above code is from Haskell FAQ. I could not find the "data Foo = Foo }" notation in my Haskell, The Craft of Functional Programming book. What does it mean? Also > instance Show Foo where > show f = show (a f) ++ " " ++ show (b f) I do not understand show (a f) either. And same goes for "foo { a = 98 }" notation. Could you help me on this notation? Thanks

2 1

Re: streching storage manager
by Marcin 'Qrczak' Kowalczyk 29 Sep '01

29 Sep '01

Sat, 29 Sep 2001 10:24:52 +0800 (GMT-8), Saswat Anand <saswatan(a)comp.nus.edu.sg> pisze: > As regard to Marcin's suggestion of using a list of compact arrays, > although elements can be accessed faster, there will be a lot if > redundancy since windows are overlapping. So consecutive arrays > will contain almost same data. I didn't mean to make them overlapping. Splitting into arrays is arbitrary. This can be made an abstract type. One possibility (perhaps another is needed): data CompactQueue a = CL [Array Int a] -- front [Array Int a] -- rear; becomes front (reversed) after front empty !Int -- block size, set during creation !Int -- offset in the head of front - this many elements -- logically don't exist !Int -- similarly, offset in the head of rear emptyQueue :: Int -> CompactQueue a -- Argument is block size. push :: CompactQueue a -> [a] -> CompactQueue a -- Add elements to the end. -- O(block_size) because it must copy one array. (!!) :: CompactQueue a -> Int -> a -- O(index/block_size). drop :: Int -> CompactQueue a -> CompactQueue a -- This can keep up to block_size elements too many in memory -- (in the head of front). Amortized O(n/block_size). When block_size is 1, it degenerates to a plain list or queue (implemented using one-element arrays). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

streching storage manager
by Saswat Anand 29 Sep '01

29 Sep '01

Hi, I need some pointers and suggestion in the following problem: I have a very large time-series data. I need to perform some operation on that. At any instant of time, I only need a window-full of data, size of window being known. Starting from the first point, I slide the window towards right and operate on the data that reside in the current window. Currently, I read all of the data to arrays which takes a lot of space and hence GC takes up lot of time. After reading "Streching Storage Manager: Weak pointers, Stable names" paper, I had a feeling that I can do something better for my problem, especially weak pointers seem to be useful. But I do not really get the thread. What I would ideally like to do is: read all the data lazily into some data structure and as I slide the window towards right, I will invalidate the data that fall before the start point of current window. By invalidating, I mean I will somehow tell the GC to reclaim that space if necessary. Is there any way in which I can do this in Haskell, or there is a better(simpler) solution for this. Thanks, Saswat

3 3

Re: streching storage manager
by Marcin 'Qrczak' Kowalczyk 28 Sep '01

28 Sep '01

Fri, 28 Sep 2001 20:28:29 +0900, Dylan Thurston <dpt(a)math.harvard.edu> pisze: > This sounds perfectly suited to Haskell's standard lazy lists. If you > only keep a pointer to the beginning of the data you need to work on, > then Haskell will automatically read in exactly as much data as you > use and GC it away after you are done with it. The downside is that > accessing elements within the window will take time O(window size). Perhaps window contents should be grouped in compact arrays (ghc provides some non-standard array variants more compact than Array). So in overall it's a list of arrays, with elements accessed as with something like l !! (i `div` blockSize) ! (i `mod` blockSize). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

RE: Haskell <-> C/C++ comunication (sockets/pipes?)
by Simon Marlow 28 Sep '01

28 Sep '01

> Can you tell me what is the problem here? > Haskell app output is redirected to C++ input app (and > vice-versa) using > pipes. (used Erays shell script sugestion) > > When I try > Hsk: 1. get, 2.send > C++: 1. send, 2 get > > It works fine, but if I try it the other way around it locks. > C++ app won't get any input. > Seems to me like Hsk is not 'flushing' the output. You may need to set the buffering mode on the handle to LineBuffering, using IO.hSetBuffering. In GHC at least, the buffering mode is set to line buffering by default if and only if the handle is connected to a terminal. Cheers, Simon

1 0

Re: Haskell <-> C/C++ comunication (sockets/pipes?)
by Marcin 'Qrczak' Kowalczyk 28 Sep '01

28 Sep '01

Thu, 27 Sep 2001 23:06:51 +0100, Jorge Adriano <jadrian(a)mat.uc.pt> pisze: > Seems to me like Hsk is not 'flushing' the output. I guess this is right (sorry, haven't checked). You can flush in two ways (using module IO): 1. At the beginning: hSetBuffering stdout LineBuffering or even hSetBuffering stdout NoBuffering (the latter slows down the I/O). 2. After each write to be flushed: hFlush stdout stdout is either line buffered or block buffered by default, depending on whether it's a terminal or not. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Re: Haskell <-> C/C++ comunication (sockets/pipes?)
by Jorge Adriano 27 Sep '01

27 Sep '01

Can you tell me what is the problem here? Haskell app output is redirected to C++ input app (and vice-versa) using pipes. (used Erays shell script sugestion) When I try Hsk: 1. get, 2.send C++: 1. send, 2 get It works fine, but if I try it the other way around it locks. C++ app won't get any input. Seems to me like Hsk is not 'flushing' the output. If this is the case, I can't really explain why it happens... if the output was not redirected I am pretty sure that, before trying to get input the output would be flushed (imagine something like putStrLn "please type an int:") So what is the issue here? Here is the code, And once again, thanks in advance. J.A. ------------------------------- Haskell app: send -> get ------------------------------- main :: IO() main = do --send hsnum putStrLn "6" -- get cnum and save num <- readLn :: IO(Int) writeFile "./reshs.txt" (show num) ---------------------------- C++ app: get -> send ---------------------------- #include <cstdio> #include <iostream> #include <fstream> nt main(){ // *get* hsnum and save int num; ofstream out("rescc.txt"); cin >> num; out << num; // *send* cnum cout << 10 << '\n' << flush; //it works without the flush return 0; }

1 0

RE: GUI Library Task Force
by Simon Marlow 26 Sep '01

26 Sep '01

> Thats great. I don't disagree. Its just a matter of priority. > So how about this agenda? Careful: we're in danger of not getting *anything* done if we try to prioritise the tasks like this. I think it's far more important to just have one complete GUI system that everyone can use, even if it isn't perfect. I'm absolutely in favour of the current GUI effort. So, when the hierarchical libraries come on-line then we'll have to rename the modules of the GUI library to place them in the hierarchy. That's not a big deal, since we're going to rename all our other library modules too. > Addendum 1: Hierarchical Library Namespace The extension is virtually finalized and all the compilers implement it. However, there's the much bigger task of actually moving over to using the hierarchically organised libraries; this effort is ongoing. We intend to move GHC over for the next version, but leave some compatibility libraries in place. > Addendum 2: Concurrency Hasn't changed much in ages, and largely independent of the others (apart from module name differences with the library hierarchy). Consider GHC's implementation as a draft proposal for a report adendum. I plan to write up a proper proposal at some point (although if someone else were to volunteer, I wouldn't complain :-). > Addendum 3: FFI Almost finalized. Again, independent apart from module names. > Addendum 4: Exceptions Consider GHC's implementation a proposal, but omit the asynchronous exception support. Hugs (in CVS) implements nearly the same interface. > Addendum 4.5?: Proc Syntax for Arrows > Addendum 5: Library Interface Compatibility Guidelines The document we've been drafting for the new library organisation has the beginnings of a set of guidelines, and contributions are of course welcome. The point I'm making is that we can parallelise these tasks to a certain extent, and that doing so is essential in order for us avoid bottlenecks and to converge at all. I agree with many of the points you raise about Haskell needing these features in order to be an "industrial strength" language, but saying things like "we must wait for X so we can do Y properly" has historically not resulted in X appearing in a timely fashion, which in turn leads to no Y at all. Manuel has done a good job of specifying the job of the GUI task force so that it doesn't depend on any of these other tasks, and I think that's the right way to go. Cheers, Simon

2 1

Haskell <-> C/C++ comunication (sockets/pipes?)
by Jorge Adriano 26 Sep '01

26 Sep '01

Hi all, I was thinking about making some GUIs in Qt/KDE for some haskell applications (compiled with ghc). My first idea was to simply run haskell applications with some args using the GUI and get the results from some file or something like that. Anyway someone told me that a better idea would be to use pipes to enable the GUI to comunicate with the application. I checked the ghc libs and there was a pipe function, but I would need named pipes here (right?) since the two processes are not related. I didn't found any function for that in the ghc libs... is there one? I was also told that another (better way) to do this would be to use sockets. I've worked a little bit with posix stuff (fork, pipes, etc) but I never worked with sockets. I was thinking about using named pipes if that's possible, anyway, Id like to know what you think. Is possible. Is sockets a good solution? better? worth the trouble of learning how to use them? Any better ideas? J.A. PS: Good luck to the GUI task force ;)

3 4