- Haskell-Cafe - Haskell.org

Arbitrary files in a Cabal package: how to install
by Dimitry Golubovsky 24 Jul '05

24 Jul '05

I am trying to use Cabal for buiding HSFFIG as a package. Among other files to install I have the special template for hsc2hs which is a C include file. If I specify it in the Includes: clause nothing happens: it is not copied anywhere during installation. I need this file to be placed somewhere in the package instalation location, so when programs are compiled with my package could include that file. Of course I may specify additional step in the Makefile, but it would be more consistent to do this in Cabal. How can arbitrary files be declared parts of a package, and destination directories for them be specified? I am using the simplified (?) version of Cabal that Ross suggested whrn I asked in this list whether it would be possible to use it with older GHC. Dimitry Golubovsky Middletown, CT

1 0

building Ghc with msvc ?
by Jan Scott 24 Jul '05

24 Jul '05

Hi, Has anyone ever tried to build Ghc with Microsofts c compiler (msvc) ? Thanks Jan

2 1

ANN: MissingH 0.11.3, now supporting Windows
by John Goerzen 23 Jul '05

23 Jul '05

Hello, I have just released MissingH 0.11.3. The big news about this version is that it now supports Windows, in addition to the continuing support for Posix platforms. Downloads and info available from: http://quux.org/devel/missingh or gopher://quux.org/1/devel/missingh -- John

1 0

How to parsing files
by yin 22 Jul '05

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 22 Jul '05

22 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 21 Jul '05

21 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 21 Jul '05

21 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