July 2005 - Haskell-Cafe

22 Jul '05

Hi, I need to parse a file in this format: float float float float float float Each row has 3-columns of floating procision number divided by white space. The number of lines is undefined. I use (lines (readFile "...")) to read the file. Thnks. Matej 'Yin' Gagyi

4 3

Re: [Haskell] Re: A MonadPlusT with fair operations and pruning
by ajb＠spamcop.net 21 Jul '05

21 Jul '05

G'day all. (Moving the discussion to haskell-cafe.) Quoting oleg(a)pobox.com: > The last statement should probably be `return (otherState w,b')', > right? Yes, I think so. > mif (mif c t' e') t e > translates to > > ((X=1 ; X=2) *-> X=1 ; fail) *-> true; true. Using the predicate: test(X) :- ( ( ( X = 1 ; X = 2 ) *-> X = 1 ; fail ) *-> true ; true ). Testing it with SWI-Prolog gives me: ?- test(X). X = 1 ; No and: ?- X = 2, test(X). X = 2 ; No and: ?- X = 3, test(X). X = 3 ; No The problem is that soft cut isn't a logical construct unless the program is well-moded. Using Mercury with the above code plus the following declarations: :- pred test(int). :- mode test(in) is semidet. :- mode test(out) is nondet. gives one appropriate answer: the "in" mode succeeds on all integers, but the "out" mode doesn't compile since X isn't bound inside the predicate. Another appropriate answer is the NU-Prolog approach, which suspends negations until they are appropriately bound. I haven't tested it, but NU-Prolog _should_ do the equivalent of this: ?- test(X). X = 1 ; X = X ; No (Read this as "X can be either 1 or anything".) You can also get an appropriate answer if your Prolog supports constraint programming, and you prime X before calling test/1. I also haven't tested this. Now Haskell programs are always well-moded, so let's see if it's an issue here. The "in" mode looks something like this: test_in :: Int -> Logic () test_in x = mif (mif (guard (x == 1) `mplus` guard (x == 2)) (\_ -> guard (x == 1)) mfail ) (\_ -> mtrue) mtrue This succeeds for all values of x. The "out" mode looks like this: test_out :: Logic Int test_out x = mif (mif (return 1 `mplus` return 2) (\_ -> guard (x == 1)) mfail ) (\x -> return x) ??? What to replace "???" with is left as an exercise for the reader. By the way, the moral of this story is that despite both being declarative, functional programming is much, much simpler than logic programming because the dataflow is simpler. In summary, I think that whether the extra law is needed or not depends on how logical your logic variables are. > In any case, we > haven't encountered a need to simplify "mif (mif c t' e') t e" > algebraically. It is interesting to see when such a law may be > required. I think you need it if you're deriving using the John Hughes method. If you didn't need it, all the better for you. Cheers, Andrew Bromage

2 2

RE: [Haskell-cafe] Re: FFI and callbacks
by Simon Marlow 21 Jul '05

21 Jul '05

On 20 July 2005 18:49, John Goerzen wrote: > On 2005-07-20, Simon Marlow <simonmar(a)microsoft.com> wrote: >> This paper might help shed some light: >> >> http://www.haskell.org/~simonmar/papers/conc-ffi.pdf > > Forgot to reply to this. *Very helpful* link, I had always wondered > what the bound thread functions in Control.Concurrent were for :-) > > So let me see if I understand this correctly. > > Let's say that I have: > > * A program that uses multiple lightweight Haskell threads (all > started with plain forkIO calls) > > * An event-driven C library, not not thread-aware, with a blocking > main loop > > * GHC 6.4 > > * My C calls all imported "safe". > > Now then, if I understand this correctly, that a call to the C main > loop will create a new bound OS thread, so it will not interrupt any > other forkIO'd threads in Haskell. Not necessarily a *bound* OS thread. A bound thread is only created by an in-call to Haskell. An out-call may happen in a separate OS thread if the foreign import is "safe", that is, another OS thread will continue to run the remaining Haskell threads while the call is in progress. > However, if one of my Haskell-based callbacks creates new threads with > forkIO, I could be in trouble; if they make any calls into C, a new > bound OS thread would be created for them, and this could wind up > causing trouble in C. I would probably need some sort of "global > MVar" to synchronize access into the C world. Bingo. This is why you need to make all your calls to the C library from a single thread. > I also have some follow-up questions after looking at the > Control.Concurrent API: > > 1. It seems that there is no function that says "block the current > thread until the thread given by ThreadId dies" You can do something like this with an exception handler and an MVar or TVar: do died <- atomically $ newTVar False forkIO (later (atomically $ writeTVar died True) $ ...) let wait = atomically $ do b <- readTVar died when (not b) retry where later = flip finally granted, it's hard to implement exactly what you were asking for. Another way to do it would be to put a finalizer on the ThreadId, but that would incur a delay until the GC discovered the thread was unreachable. Hmm, perhaps we should have threadIsAlive :: ThreadId -> STM Bool > 2. What is the preferred way to implement a simple lock? With an > MVar? TVars are the way to go, although MVars do perform slightly better at the moment (at least if you stick to the simple putMVar/takeMVar operations). Cheers, Simon

4 4

RE: Re[2]: [Haskell-cafe] Re: FFI and callbacks
by Simon Marlow 21 Jul '05

21 Jul '05

On 21 July 2005 08:07, Bulat Ziganshin wrote: > Hello Simon, > > Thursday, July 21, 2005, 1:16:10 AM, you wrote: > >>> However, if one of my Haskell-based callbacks creates new threads >>> with forkIO, I could be in trouble; if they make any calls into C, >>> a new bound OS thread would be created for them, and this could >>> wind up causing trouble in C. I would probably need some sort of >>> "global MVar" to synchronize access into the C world. > >> Bingo. This is why you need to make all your calls to the C library >> from a single thread. > > you can either: > 1) made all calls from single thread > 2) put all calls in "withMVar lock", where `lock` is a global MVar You can't always do (2), because some libraries (eg. OpenGL) use per-thread state. So you really can only call into OpenGL from a single thread, and it must always be the same thread (this is why we introduced bound threads, as it happens). Cheers, Simon

1 0

RE: [Haskell-cafe] Updating the Haskell Standard
by Simon Peyton-Jones 21 Jul '05

21 Jul '05

| I think an updated standard is overdue. I find it difficult anymore to | write any but the most trivial of programs using pure Haskell 98. Some | notable, and widely-used, features developed since then include: | | * Overlapping instances | * FFI | * Hierarchical namespace | * Undecidable instances | * All sorts of updates to the standard library In fact there's a well established way to express the results of such an exercise: an Addendum to the Report. Two of the things you mention here already are Addenda http://haskell.org/definition/ namely FFI and hierarchical namespaces. [Actually, for the latter, the Addendum seems to be stuck at 0.0, and doesn't have any names attached to it. So it's in a kind of limbo, but there's a draft at least.] These Addenda are useful for exactly the reasons you describe: to solidify and nail down the details of particular language extensions. How do Addenda get written? The Haskell community is a particularly informal one. There is no Haskell committee. Instead, someone gets up sufficient motivation to gather a bunch of people and write a document. It's a good idea to publish regular drafts, and ensure that any one interested can see and contribute, because ultimately the usefulness of the Addendum depends on its acceptance. In short, the way lies open. The only bottleneck is people willing to do the work. I think that many of the people who produced the existing Haskell Report feel that they've done their bit, and perhaps someone else can have a go. That's certainly what I feel -- doing the Haskell 98 book was a *lot* of work -- though I would gladly contribute to an effort driven by someone else. To my mind, for all the fun of overlapping instances, the single thing that would be most useful in this area would be more well-documented, well-engineered libraries. The last year or two have seen lots of really useful-looking new libraries coming along. But bringing all that under a single roof, rather as the Haskell Library Report did, with reasonable documentation and compatible conventions, would be a great service. It would also be Real Work. Simon

2 1

RE: [Haskell-cafe] FFI and callbacks
by Simon Marlow 20 Jul '05

20 Jul '05

On 20 July 2005 16:23, John Goerzen wrote: > On Wed, Jul 20, 2005 at 04:10:38PM +0100, Simon Marlow wrote: >> On 20 July 2005 14:35, John Goerzen wrote: >>> These systems generally have some sort of an opaque main loop, >>> implemented in C. This loop would usually never return, or perhaps >>> only return once the UI is destroyed. >> >> Is the library thread-safe or not? I mean OS-thread safe. If it is, >> then you're home and dry: just compile your program with GHC's >> -threaded option, and any foreign calls that need to run >> concurrently with Haskell threads must be declared "safe" (which is >> the default in fact, so instead I should really advise you to mark >> all calls that don't need to run concurrently as "unsafe", because >> that's good for performance). > > That's half of the question. The other half is: what is the canonical > way of handling this mainloop that doesn't return from Haskell? Do we > just treat it that way in Haskell as well, or would some people forkIO > it? You could forkIO the main loop if you want; it shouldn't make any difference, except that GHC terminates the program when the main thread completes, so it's more convenient to have the main loop run in the main thread, so that the program terminates when the main loop returns. > Does any part of your answer vary depending on whether the Haskell > threads in question are forkIO threads or forkOS threads? I imagine > that it might. No, and I don't think you need forkOS here. This paper might help shed some light: http://www.haskell.org/~simonmar/papers/conc-ffi.pdf >> If the library isn't thread-safe, then you're in the same boat as Gtk >> and wxHaskell (I believe) where there are known problems with having >> a multithreaded Haskell GUI app. You can only have one OS thread >> (and hence only one Haskell thread) doing GUI operations, and that >> is the > > What about multiple forkIO threads? You should think of Haskell as having a one-to-one mapping between OS threads and Haskell threads. The only difference between forkIO and forkOS is that a forkIO thread can migrate from one OS thread to another, whereas a forkOS thread always runs on the same OS thread. This difference is therefore only visible when you make FFI calls, because there's no way in Haskell to tell what OS thread you're running on. In practice, GHC uses an optimised implementation to take advantage of the fact that forkIO threads are allowed to migrate from one OS thread to another, and it runs all the forkIO threads using a small pool of worker OS threads. The design of forkIO/forkOS and the FFI is carefully crafted to accommodate both GHC's optimised implementation and simpler implementations such as one-to-one or a giant lock. >> thread in the main loop. You have to somehow set up a communication >> between your other Haskell threads and the thread running the main >> loop - perhaps you can send requests of type (IO ()) down a channel >> to the main loop thread which wakes up occasionally to run them, for >> example. > > I imagine there could be exceptions to this.. For instance, perhaps a > given operation needs to do 5 things, perhaps simultaneously, before > displaying a result. It could, perhaps, fire off five threads and > just not display a result until all five have terminated, yes? Sure, but it's just a matter of converting direct GUI calls into RPCs to the GUI thread, using some appropriate RPC mechanism. Cheers, Simon

2 2

Re: [Haskell-cafe] Best way to build strings?
by Frank-Andre Riess 20 Jul '05

20 Jul '05

Hello there, > I'm very fond of Python's interpolation approach, where we'd have > something like the following for the External case: > > def __str__(self): > return "(%s [] %s)" % (self.p, self.q) are you familiar with C's printf procedure? It's where that kind of notation comes from. You can use Text.Printf which provides the function printf :: PrintfType r => String -> r Thus you can write show (Prefix l p) = printf "(%s->%s)" l q show (External p q) = printf "(%s [] %s)" p q Alas, I couldn't test it, because the Text module seems to not be installed on my computer (sad thing not being the admin, isn't it?) Nevertheless, take a look at http://www.haskell.org/ghc/docs/latest/html/libraries/base/Text.Printf.html Regards, Frank-Andre Riess

1 0

file line operation perhaps need loop
by Sun Yi Ming 20 Jul '05

20 Jul '05

Hello, I have two txt file,and i want to mix the two files line by line, e.g. $ cat url1.txt url1_1.line url1_2.line $ cat url2.txt url2_1.line url2_2.line and i want this file as result: $ cat aha.txt url1_1.line url2_1.line url1_2.line url2_2.line i first write this snippet of code: --- import System.IO mix :: [a] -> [a] -> [a] mix [] ys = ys mix xs [] = xs mix (x:xs) (y:ys) = [x,y] ++ mix xs ys f1 = do contents1 <- readFile "url1.txt" contents2 <- readFile "url2.txt" let urls1 = lines contents1 urls2 = lines contents2 urls = mix urls1 urls2 writeFile "aha.txt" (unlines urls) -- this works fine, but i think if the two file are very big, and the readFile will consume too many mem.so i need to read the file line by line but stunned by the loop in IO Monad: --- main = do h1 <- openFile "url1.txt" ReadMode h2 <- openFile "url2.txt" ReadMode line1 <- hGetLine h1 line2 <- hGetLine h2 print $ line1 : line2 : [] -- i don't howto do hClose h1 hClose h2 -- any ideas? thank you all. -- Sun Yi Ming

6 6

RE: [Haskell-cafe] FFI and callbacks
by Bayley, Alistair 20 Jul '05

20 Jul '05

> From: John Goerzen [mailto:jgoerzen@complete.org] > > How would I make this sort of system play nice with Haskell threads? > > Also, the brief FFI docs that I've found don't really explain > callbacks > in FFI very well to me. Are there any other resources on > this anywhere? This might help: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign.Ptr.html# t%3AFunPtr ...and I can also show you some code which uses a simple callback. Or are you past that stage now, and more worried about interaction of callbacks and threads? Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

FFI and callbacks
by John Goerzen 20 Jul '05

20 Jul '05

Hi, I'm looking at packaging an event-driven console widget set (CDK) for Haskell using FFI. I know that other event-driven widget sets have Haskell bindings, but I'm not quite sure how to make everything play nice with forkIO. These systems generally have some sort of an opaque main loop, implemented in C. This loop would usually never return, or perhaps only return once the UI is destroyed. How would I make this sort of system play nice with Haskell threads? Also, the brief FFI docs that I've found don't really explain callbacks in FFI very well to me. Are there any other resources on this anywhere? Thanks, -- John

1 0