- Haskell-Cafe - Haskell.org

FFI and DLLs
by Lewis-Sandy, Darrell 04 Sep '07

04 Sep '07

An early proposal for the FFI supported importing functions directly from dynamic link libraries: www. <http://www.haskell.org/hdirect/ffi-a4.ps.gz> haskell.org/hdirect/ffi-a4.ps.gz This looks like it was dropped from the final version of the addendum in favor of C header files as the sole form of import entities. Not being a C programmer, how would one go about importing a foreign function (e.g. void Foo(void) ) from a dynamic link library (e.g. foo.dll)?? Would someone be willing to provide an explicit example?

2 1

Re: [Haskell-cafe] [Off topic] Proving an impossibility
by Miguel 04 Sep '07

04 Sep '07

>On 9/3/07,Vimal<j.vimal(a)gmail.com> wrote: >>while E do >>S >>if F then >>break >>end >>T >>end >> >>He then asked us to *prove* that the above programming fragment cannot >> >>be implemented just using if and while statement, even if S and T can >>be duplicated a finite number of times >But it IS possible. Just add a boolean flag: Possibly, you are not allowed to change the sequence of machine operations at all. See, if you change "while(A){B}" to "if(A){B};while(A){B}", the sequence is exactly the same; but it's not possible in this case. It reminds me of a paper by Knuth, where he states that "goto" statement is necessary; don't remember the title, however.

2 1

Are type synonym families really equivalent to fundeps?
by Chris Smith 04 Sep '07

04 Sep '07

The following code builds and appears to work great (assuming one allows undecidable instances). I have tried both a natural translation into type synonym families, and also the mechanical transformation in http://www.cse.unsw.edu.au/~chak/papers/tyfuns.pdf -- but I can't get either to work. The two fishy things are: 1. There is a functional dependency (a -> t) in the original. Actually, this isn't always true since t is sometimes not uniquely determined by a; but GHC always seems to do the right thing anyway. There doesn't seem to be any way to "cheat" like this with type families. 2. In the second and fourth instances, the type variable x appears twice in the parameters of the type function built from the fundep (a b -> c). This causes an error. If I try adding (x ~ x') to the context and making one of them x' instead of x, I get different errors. I'm starting to this this is an example of using functional dependencies that has no translation to type families. Can anyone free me of such thoughts? Code with fundeps is: data Var a = Var Int (Maybe String) data RHS a b = RHS a b class Action t a b c | a -> t, a b -> c, a c -> b instance Action t () y y instance Action t (Var x) (x -> y) y instance Action t [t] y y instance (Action t a b c) => Action t (RHS (Var x) a) (x -> b) c instance (Action t a b c) => Action t (RHS [t] a) b c -- Chris Smith

4 7

Hawiki articles
by Henning Thielemann 04 Sep '07

04 Sep '07

In the current Haskell Wiki (haskell.org/haskellwiki) I found references to articles of the old Hawiki (haskell.org/hawiki) like OnceAndOnlyOnce and SeparationOfConcerns. Are the files still available somewhere?

7 14

Haskell as an extension language
by Yuri D'Elia 04 Sep '07

04 Sep '07

Hello everyone; I've been using haskell for quite some time now, but, as usual, I still find myself resorting to c code too much often due to the performance penalty introduced. FFI is all nice and dandy, yet, the need to compile the code and separate the implementation in two is a mayor development issue I'd like to eliminate along with batch compilation. In the way I like to work, I only use the interpreter (I mainly started with this approach with ocaml); just program interactively; close the whole session and pretend to resume the work next time I reopen the interpreter. Unfortunately, the interpreted performance is, many times, not sufficient for my purposes. In the past I've been coding several programs that would allow the user to extend the functionality at runtime through real c code. The "host" program itself could start an internal editor that accepted c code. The code would then be sent to the system compiler, generating a dynamic object that would be loaded in the current program (and executed) immediately. With some voodoo usage of "unexelf", I could create a simple runtime environment with very good performance (except for the initial compilation delay), interactivity and persistence, but, as you might expect, almost no resilience to errors and difficult debugging issues. I would like to resume this idea. Programming the core (minimal) application in c and then adding an extension mechanism always led to better and faster programs in my experience than trying to use directly an higher-level language and (ab)use the various forms of FFI. UI latency was one of the primary reasons in many cases. The amount of c code needed was always lower too, in the end, as the code was extended beyond the original minimal requirements. The extensions, being wrapped around the core data structures, tended to be more specialized and concise than general all-purpose libraries. Has anyone experienced similar situations? Is there some documentation about integrating an haskell interpreter in host programs that would allow session persistence and some minimal form of debugging? Which interpreter works better in this context? Thanks

5 8

Re: [Haskell-cafe] GHC 6.6.1 and SELinux issues
by Alexander Vodomerov 04 Sep '07

04 Sep '07

On Tue, Aug 28, 2007 at 08:53:05PM -0600, Stuart Jansen wrote: > On Wed, 2007-08-29 at 00:59 +0400, Alexander Vodomerov wrote: > > In what domain do you run GHC? > > Sorry about that, should've dug deeper. And here we have the difference: > > $ ls -Z /usr/lib/ghc-6.6.1/ghc-6.6.1 > -rwxr-xr-x root root > system_u:object_r:unconfined_execmem_exec_t /usr/lib/ghc-6.6.1/ghc-6.6.1 This explains that GHC works fine. unconfined_execmem_exec_t gives permission to map memory with PROT_EXEC and PROT_WRITE simultaneously. I've put GHC in unconfined_execmem_t and it started to work fine. But the problem is not in GHC -- it is in programs compiled by GHC. They also require exec/write memory. Only root can grant unconfined_execmem privileges, so simple user can not run binaries compiled by GHC. How do you solve this problem? Does Fedora GHC package has any additional patches? With best regards, Alexander.

6 8

ANN: HPDF 1.0
by alpheccar 04 Sep '07

04 Sep '07

I am pleased to release the version 1.0 of my PDF library that you can find on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HPDF-1.0 This email is mainly an opportunity for me to thanks apfelmus who, a very very long time ago when I released HPDF for the first time, gave me very good advices. When you're new to a language, that kind of help from the community is always very appreciated. Christophe.

1 0

Closures and pointfree functions
by Lars Oppermann 04 Sep '07

04 Sep '07

Dear all, In the Haskell Wiki at http://www.haskell.org/haskellwiki/Closure there is an example for a function returning a closure given as f x = (\y -> x + y) Another way to achieve the same effect would be to write f' x = (+) x which to me as a beginner looks somewhat like pointfree style. Would f' be considered to return a closure? Bests, Lars

2 3

Update on monad subexpressions
by Chris Smith 04 Sep '07

04 Sep '07

I know a lot of you are very interested in my planned work on implementing monad subexpressions -- that is, (<- f) notation -- in the GHC compiler. Unfortunately, it's becoming clear that I'm not going to get to it any time soon. Between having a full time job, being a full time student, applying to graduate schools, and some volunteer work that I'm not willing to give up, I simply have no remaining time, and won't until about December or later. If someone else wants to pick up this project, please go for it. Otherwise, I'll get to it when I do. Sorry! -- Chris Smith

1 0

Closures in Haskell and closures in set theory
by Peter Verswyvelen 04 Sep '07

04 Sep '07

If I'm not mistaken, in set theory, a closure of R with respect to some property P is the smallest superset R* that has the property P. To me, intuitively, a closure C in programming languages is a function that has bindings to variables declared in "parent" functions; so the inner function can not exist on its own, it needs a "parent environment". This seems to be related to set theory if we define R as the set of parameters of C, and R* as this set extended with the "parent variables" to which C binds, and P as the property "C can be evaluated". Does this make any sense at all?

1 0