- Glasgow-haskell-users

question about kinds
by Hal Daume III 18 Jan '02

18 Jan '02

I have the following definition: > class Traversable d where > traverse :: d a -> (Maybe a, [d a]) And the standard binary tree data type: > data Tree a = Branch (Tree a) (Tree a) > | Leaf a I can define both Tree and [] to be instances of Traversable: > instance Traversable Tree where > traverse (Leaf a) = (Just a, []) > traverse (Branch t1 t2) = (Nothing, [t1,t2]) > instance Traversable [] where > traverse [] = (Nothing, []) > traverse (x:xs) = (Just x, [xs]) Now, I want to say that if some data type 'd' is Traversable and another data type 'e' is Traversable, then the "combined data type" is Traversable. That is, for example, I want to say that a Tree of Lists is traversable, or that a List of Trees, or a List of Lists is traversable. But I can say neither: > instance Traversable (Tree []) where ... or: > instance (Traversable a, Traversable b) => Traversable (a b) where .. Because of the obvious kind errors. What I suppose I need is some sort of lambda expansion over kinds, so I could say: > instance (Traversable a, Traversable b) => Traversable (\x -> a b x) or something like that. Obviously this doesn't exist. How can I get around this? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume(a)isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

1 2

bug report trouble?
by Feuer 17 Jan '02

17 Jan '02

I sent a bug report recently to glasgow-haskell-bugs(a)haskell.org. I have not seen any response to that message, or in fact any (non-spam) messages on the list after it. Is this still the right place to send bug reports? If not, where should I send it? David Feuer

2 1

Re: FFI
by Sven Panne 16 Jan '02

16 Jan '02

Manuel M. T. Chakravarty wrote: > I think, there are five options: > > * H/Direct (you mentioned that already) > * GreenCard (ditto) > * C->Haskell > http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ > * hsc2hs (comes with GHC) > * Plain FFI Plus: * Write your own IDL compiler for a given formal description of an API This sounds a little bit like overkill at first, but at least for my never-ending HOpenGL project it makes a lot of sense: There is a rather large (maintained!) description of the OpenGL API (plus a few more things like GLX) at http://oss.sgi.com/cgi-bin/cvsweb.cgi/projects/ogl-sample/main/doc/registry… which could be used to generate header files, network code for GLX, stubs, etc. (and of course a low-level Haskell binding :-) Of course one could hack H/Direct in a way that it understands these .spec files, but a home-grown compiler was the easier and more tunable way. I hope to release a new version of HOpenGL based on this "soon". :-} SimonM has written a small program/hack to auto-generate something for GTK+, IIRC, so I'm probably not alone on this route... I agree with Koen on his points: * Plain FFI plus a few combinators is not so bad at all for small to medium-sized bindings. Only the mapping of Haskell enumerations to C enums/ints and back is *really* boring... * No tool whatever generates a Haskellish binding one wants to present to an end user, so a wrapper around the lower Haskell level is necessary, anyway. Manuel: Could the results/opinions of this thread added somewhere? I'm not sure where, the libraries/tools page of haskell.org is a possibility, but your page could be used, too. Cheers, S. -- Sven Panne Fon: +49/89/99567000 Fax: +49/89/99567461 BetaResearch GmbH, Betastr. 1, D-85774 Unterfoehring mailto:Sven_Panne@BetaResearch.de http://www.betaresearch.de

1 0

FFI
by Mark Conway Wirt 14 Jan '02

14 Jan '02

I'm looking for opinions as to the best way to do a C (or C++) foreign interface to GHC haskell code. It looks like there are three options. Greencard has been around for a while, but it looks as if it's more-or-less deprecated now; I don't see many people talking about it anymore. Unless I'm wrong about this (and if I am, please disabuse me of this bias), it doesn't sound like the obvious choice. That leaves me with GHC's FFI and hdirect. I've played around a bit with hdirect in ghc-5.02 and it works. I haven't really looked at the native FFI (beyond reading some manual pages), so I'm not really sure what hdirect provides that the FFI doesn't. From a cursory glance it looks like hdirect's ihc is useful for auto-generating interface files, but it may be over-kill for my smallish project. Any feedback or personal biases are welcomed. Thanks, --Mark

6 9

Multiply Recursive Modules
by George Russell 14 Jan '02

14 Jan '02

Writing .hi-boot files is a pain, and "the works" (allegedly) containing a compiler which does mutually recursive modules properly seem permanently gummed up. Therefore may I suggest a new .hs-boot suffix which compiles Haskell to produce just a .hi-boot file? I already have two .hs-boot files (except I call them .boot.hs to make ghc happy) and they seem to work reasonably well.

1 0

Re: multithreading with multiprocessing (Was: Concurrent and Posix libraries...)
by Dean Herington 14 Jan '02

14 Jan '02

It turns out that, besides having a multithreaded process do `forkProcess` and `executeFile` "atomically", I also want to have a multithreaded process do `forkProcess` (without `executeFile`) and execute without any of the preexisting threads. This can be done by having a lock that all threads acquire before doing anything externally visible (roughly, any `IO` action), including, of course, the `forkProcess` itself. This solution, however, is cumbersome and probably inefficient. If a foreign function invocation designated "unsafe" is atomic with respect to the Haskell RTS, even when OS threads are used, there must be an internal mechanism in the Haskell RTS for temporarily running single-threaded. Why couldn't (and shouldn't) this mechanism be available to user programs? It would seem to be much cleaner and more efficient than the locking approach described above. Dean Simon Marlow wrote: > This example raises a general problem (which, as it turns > out, is relevant > to my current work). How can one mix multithreading with > multiprocessing? In particular, how can a threaded process > safely create > another process to run a program? Put another way, how can the > combination of `forkProcess` and `executeFile` be done > "atomically enough" > so that existing threads in the forking process don't "get in > the way". > > I read something on this topic (involving some sort of > pervasive locking > strategy) recently, but can't recall where. Anybody remember? I can't think of a good way to do this at the Haskell level, because you'd need to halt all the running threads except for the one doing the fork. But one hack which will work is to call out to a C function which does the fork/exec, since foreign calls will be atomic from the point of view of the Haskell RTS. However, one caveat which might be relevant in the future is that if the Haskell program is running in a multi-threaded environment (i.e. OS threads, not Haskell threads), then the C function must be marked 'unsafe' for it to be treated as atomic by the Haskell RTS. The OS thread support in the RTS isn't fully implemented yet, though. Cheers, Simon

1 0

Re: GHC Poll: scope in GHCi
by Ketil Z Malde 14 Jan '02

14 Jan '02

Koen Claessen <koen(a)cs.chalmers.se> writes: > | Does anyone have any better suggestions? > I think any solution that leaves it transparent as to if it > is a compiled or an interpreted module is fine. > But I have understood that this is hard to achieve... How about using a different command for importing the exported interface only? I.e. :l M --loads the whole (internal/top level) module :i M --"imports" the module's exported interface If :l requires interpretation, then so be it, otherwise use compiled modules whenever possible. I'm not sure I see the need for "namespace combinators" (ie. SM's suggested :m +M and so on) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

RE: GHC Poll: scope in GHCi
by Simon Marlow 14 Jan '02

14 Jan '02

> | Does anyone have any better suggestions? > > I think any solution that leaves it transparent as to if it > is a compiled or an interpreted module is fine. I'm currently showing the scope in the prompt, with the modules from which we're taking the exports only surrounded by square brackets. Eg. [Prelude]> Just the exports of the Prelude are in scope [Prelude,IO]> The exports from Prelude and IO are in scope Main> The whole top-level scope of module Main Main[IO]> The whole top-level scope of Main, plus additionally the exports of IO A,B> The combined top-level scopes of A and B. So this doesn't really tell you which modules are compiled vs. interpreted but it does give you a good indication of what the current scope is. I can easily add another command to show the currently loaded modules, including which ones are interpreted - something like > :show modules Main ( Main.hs, interpreted ) Foo ( Foo.hs, Foo.o ) And maybe > :show bindings x :: Int f :: Int -> Bool Any other show-type things that might be useful? Cheers, Simon

3 2

Re: Yell
by Ashley Yakeley 13 Jan '02

13 Jan '02

At 2002-01-12 10:22, Hal Daume III wrote: >This seconds the yell. In the mean time Hugs has some documentation: http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/exts.html#sect7. 4 -- Ashley Yakeley, Seattle WA

1 0

Yell
by Ashley Yakeley 12 Jan '02

12 Jan '02

This message constitutes a yell. http://www.haskell.org/ghc/docs/latest/set/implicit-parameters.html Thanks in advance... -- Ashley Yakeley, Seattle WA

2 1