April 2010 - Haskell-Cafe

Re: [Haskell-cafe] Cabal, GHC and Preprocessors
by Ashley Yakeley 12 Apr '10

12 Apr '10

On Mon, 2010-04-12 at 06:51 +0100, Malcolm Wallace wrote: > Even without that, it may be possible to get what you want, using > -pgmPcpphs -optP-cpp -optP-ansi > that is, to override ghc's addition of -traditional with -ansi. > However I'm not sure exactly what order the preprocessor arguments > will reach cpphs - in a choice between -traditional and -ansi, it is > the last one on the cpphs commandline that will take effect. This worked in my .cabal file: cpp-options: --cpp -ansi ghc-options: -pgmPcpphs Thanks! -- Ashley Yakeley

1 0

Cabal, GHC and Preprocessors
by Ashley Yakeley 11 Apr '10

11 Apr '10

I want identifier concatenation in Haskell. For instance: #define CDecl(n) = class C_##n a where { f_##n :: a }; CDecl(1) CDecl(2) CDecl(3) (Actual motivator involves generating by type kind.) I have no trouble switching on CPP, but this doesn't work. The trouble is, GHC uses gcc for preprocessing, and it passes "-traditional" which switches this off. There doesn't seem to be a flag to override this. I've tried replacing the GHC preprocessor with cpphs using -pgmP, but GHC passes include files using "-include", while cpphs only accepts "--include". I've tried telling Cabal to use cpphs, but even if you rename the source file to .cpphs, it will still use GHC's gcc preprocessor rather than cpphs. In any case, it's not clear how to tell Cabal to pass --hashes to cpphs. I've tried using Template Haskell instead, but you can't easily splice identifiers, only expressions, types and top-level declarations. -- Ashley Yakeley

1 0

haskell gsoc proposal for richer numerical type classes and supporting algorithms
by Carter Schonwald 11 Apr '10

11 Apr '10

Hello All, I would like to know if there is enough community interest in following gsoc project proposal of mine for me to write up a proper haskell gsoc app for it . (and accordingly if there is a person who'd be up for having the mentoring role) Project: Alternate numerical prelude with a typeclass hierarchy that follows that found in abstract algebra, along with associated generic algorithms for various computations can be done on datastructures satisfying these type clases. In particular, the motivating idea is the following: yes it'd be useful (for more mathematically inclined haskellers) to have a numerical prelude whose hierarchy means something, but for even that subset of the haskell user population, such an alternate prelude is only useful if users get extra functionality out of that more detailed infrastructure (and I believe that some of the infrastructure that becomes feasible would be worthwhile to the larger haskell community). the basic plan is as follows 1) define a typeclass hierarchy that covers everything such as monoids - groups - rings - fields, and various points in between. After some experimenting, it has become pretty clear to me that all of these need to be defined indirectly with the help of template haskell so that the names of the various operators can be suitably parameterized (so that * and + etc aren't the only choices people have). This part itself isn't terribly difficult, though theres a lot of important intermediate algebraic structures that also need to be defined, and as I currently plan it, i'm very much inclined towards specifying all the required properties of each algebraic structure as testable properties, so that in a certain sense all these type clases could be interpreted as "adding facts" to an inference engine . This part is easy, just a lot of support type classes which a user wouldn't often encounter or deal with unless they're doing real math, in which case understanding them is probably key for correctly writing the desired code anyways. For those reading this who don't know the abstract algebra terminology: *a monoid* is a set with an operation "+" which has an identity element, an example would be lists and the append operation. *a group * is a monoid where the operation is invertible, it could be something as simple as positive rational numbers under multiplication or the various translations and rotations that one does to 3d objects such as when doing open gl programming where in this latter case the "*" or "+" operation is composition of these (invertible) transformations *a ring *will have both a "+", and a "*", and the "+" will be a group over the set of objects in the ring and the "*" a monoid, over the objects in the ring. a simple example would just be the integers with + and * as they usually are. Plus some rules about 0 and 1. *a field * would be a ring where all the nonzero elements are invertible with respect to multiplication (ie nonzero elements form a multiplicative group). A standard example would be rational numbers with the standard + and * and so forth for many other algebraic objects. 2) providing algorithmic machinery that makes this all worthwhile: in particular there are two veins of algorithmic machinery that would be goals of the gsoc project, one which is certainly feasible, and the other which i'm still working out the design details for but feel is very likely. respectively: a) generic algorithms for various standard algebraic computational problems, for example a generic euclidean algorithm that will work on any sort of data structure/object/algebraic thingy that satisfies all the necessary algebraic properties (such as multivariate polynomials!), with specialized versions for various cases where better algorithms are known and the nature of the representation can be exploited (eg binary gcd on the integers). This part of the project would essentially be me going through some computational number theory /algebra texts such as http://www.shoup.net/ntb/ (A Computational Introduction to Number Theory and Algebra) and implementing every interesting/useful algorithm both generic and specialized variants. As haskell's numerical typeclass hierarchy currently stands, it is impossible to implement generic versions of these algorithms in haskell, and I don't think any widely used language aside from haskell (except perhaps scala?) even has the right abstraction facilities to make it feasible. Of course certain specialized cases would even benefit perhaps by actually having them be in turn implemented in a more low level fashion (eg via some external c/c++ library), but that itself is not really important for the core project and would be beyond the scope of a single summers work. b) because the type classes would directly encode what manipulations and equational reasoning steps are valid, the same information could be used to safely do computer assisted algebra/mathematics. In particular, the various types which are instances of algebraic type classes (say Field Rationals) could also be indexed by a sort whose members are CAS and Value, so (Field (Rationals Value)), and depending on what the context expects, we either get a computation, or a lightweight way of lifting mathematical expressions into a higher order abstract syntax! Then it would be possible to do interesting things like symbolic differentiation of functions, eg polynomial expressions etc. For this latter deliverable, theres still a few questions and problems I'd need to work out (such as how names are handled and what sort of primitive operations should be used/exposed), but nothing that seems insurmountable to making it work, and in a fairly light weight way for the end user at that! any constructive feedback would be very appreciated, please note that while irrespective of gsoc summer funding considerations I'm planning on putting this together... the funding would mean that I wouldn't have a day job taking up a good chunk of my time/energy for this coming summer. Also, I do in fact have enough of an algorithms, pl, and math background to undertake this project, though I'll leave that info for the gsoc app if there proves to be an interest in the proposal. again, thanks for any feedback! -Carter Schonwald

9 13

libraries and executables in cabal
by Paul Brauner 11 Apr '10

11 Apr '10

Hi, i'm working on a project made of - lots of modules - one excutable importing these modules - another excutable importing these same modules I don't especially want to expose those modules as libraries, especially on hackage, since they are meaningless without the executables. But, if I declare two executables in my .cabal file, cabal will compile all those modules two times each time I want to compile the executables. Is there a way to tell cabal that those modules should be considered part of a "private" library ? Paul

3 2

developing against privately patched libraries, and cabal
by Dougal Stanton 11 Apr '10

11 Apr '10

If you're making local changes against a library you don't own (with the ultimate intention of sending those changes back upstream to the library maintainer) it makes sense change the version number to avoid clashes with the canonical version of the library. Of course, it's easy to lose track and end up publishing your own program against a non-existent (outside your hard disk) version of the library. I'd like to make it very obvious, both in mypogram.cabal and library.cabal that one is a patched copy and the other has to be compiled against a patched copy. Does cabal provide any way of marking a version private? I thought initially to just mark the version field in the patched library as X.y-dougal and enforce my program to compile against that, but it doesn't seem to recognise the -dougal suffix there. Thoughts? D -- Dougal Stanton dougal(a)dougalstanton.net // http://www.dougalstanton.net

5 6

Alternative dependencies in Cabal file
by Matthias Reisner 11 Apr '10

11 Apr '10

Hi, for a package I need to ensure the user uses a certain package configuration. So how would I rewrite the following pseudo-cabal description? Build-Depends: packageA < X, packageB < Y or packageA >= X && < X', packageB >= Y && < Y' or packageA >= X', packageB >= Y' Build-Depends: ... common dependencies ... where neither A nor B is the base package. Maybe I have to use if/else blocks, but I don't know what conditions to use then. Regards, Matthias

4 4

passing cpp options to c2hs from cabal
by Chris Casinghino 11 Apr '10

11 Apr '10

Hi all, I have a question about cpp, c2hs and cabal. The short version: What can I put in my cabal file to get "-cppopts=-U__BLOCKS__" passed as an argument in calls to c2hs? Longer story: I need to set up my cabal file so that c2hs gets this extra option to make things build smoothly on some macs. If I run cabal from the command line, I can pass it: cabal install --c2hs-options='--cppopts=-U__BLOCKS__' And this works great. I need to make my .cabal file do this, but c2hs-options doesn't seem to be accepted there. I tried: cpp-options: "-U__BLOCKS__" But if I run cabal install -v I can see this isn't being passed on to c2hs: ... /home/ccasin/.cabal/bin/c2hs --include=dist/build --cppopts=-D__GLASGOW_HASKELL__=610 --cppopts=-Icontrib/libpuz/include --output-dir=dist/build --output=Codec/Game/Puz/Internal.hs ./Codec/Game/Puz/Internal.chs ... Thanks! --Chris Casinghino

3 3

Difficulties installing LLVM bindings
by Aran Donohue 11 Apr '10

11 Apr '10

Hi Haskell-Cafe, I can't get the LLVM bindings for Haskell to install. Does anyone know what I might need to do? Has anyone seen this error before? Here's the problem: (Installing from latest darcs source) llvm-haskell aran$ cabal install Resolving dependencies... ...snip... checking for unistd.h... yes checking llvm-c/Core.h usability... yes checking llvm-c/Core.h presence... yes checking for llvm-c/Core.h... yes checking for LLVMModuleCreateWithName in -lLLVMCore... no configure: error: could not find LLVM C bindings cabal: Error: some packages failed to install: llvm-0.7.0.1 failed during the configure step. The exception was: exit: ExitFailure 1 I've got the latest LLVM (from source) installed using the default "sudo make install", i.e. into /usr/local. Using cabal install --configure-option --with-llvm-prefix=/usr/local doesn't change the result. LLVM is indeed based in /usr/local. The binaries are in /usr/local/bin/, libLLVM*.a is in /usr/local/lib, etc. Google just shows that this error has cropped up a couple times before. I tried manually disabling the check in the configure script but then generating code fails with massive run-time errors that look like link problems. I'm on an up-to-date Snow Leopard, using the latest llvm bindings from darcs, cabal-install 0.8.0, cabal library 1.8.0.2, ghc 6.12.1, and LLVM from svn. LLVM works fine from C++, at least. I worked through the Kaleidoscope tutorial and a few hand-coded .ll files without a hitch. Have you seen anything like this before? Any tips or things to try? I can't think of what magic setting I'm missing. Thanks, Aran

4 7

Multiple versions of a cabal package Or what's the right way to update?
by david fries 11 Apr '10

11 Apr '10

Dear Caféistas I desperately need your collective knowledge I have been working on porting the haskell-platform to the FreeBSD operating system for a while now and some versioning issues have come up. FreeBSD is still running on GHC-6.10.4 (6.12 is in the works). The ghc package contains a couple of libraries that ghc is built against and requires to run. For instance, network-2.2.1.2 is one of them. The problem is that the Haskell Platform requires version 2.2.1.4. Under normal circumstances we would port network-2.2.1.4 to FreeBSD and then specify it as a dependency of the Platform port. But then we end up with two (exposed) versions of network installed on the system. For example, let's assume that I have the following Haskell source (Networking.hs): module Networking where import Data.ByteString.Lazy import Data.Maybe import Network.HTTP import Network.Stream import Network.URI getBinary :: String -> IO ByteString getBinary url = do uri <- return $ fromJust $ parseURI url rsp <- simpleHTTP $ request uri getResponseBody rsp where request uri = Request { rqURI = uri , rqMethod = GET , rqHeaders = [] , rqBody = empty } When I try to compile it (`ghc --make Networking.hs`) I get the following: Networking.hs:12:30: Couldn't match expected type `network-2.2.1.2:Network.URI.URI' against inferred type `URI' In the first argument of `request', namely `uri' In the second argument of `($)', namely `request uri' In a stmt of a 'do' expression: rsp <- simpleHTTP $ request uri However, the following thing could help: $ ghc --make Networking.hs -package network-2.2.1.2 The workaround ain't acceptable to the FreeBSD committers, so I have to come up with something better... In a perfect world, I'd be able to install the required HP dependencies without tripping ghc up. Then we could switch over to the platform as a foundation of GHC-6.12. I have lots of questions. Is it smart to have multiple installed versions of the same library? Up until now, we could avoid such situations. What would be the correct approach to updating network? I guess it would involve rebuilding all installed packages that had previously been compiled with ghc? Though I hope not - our package management system could pull that off if necessary. If it is perhaps a bad idea to update certain "core" libraries, is there a way to declare them as such in the cabal file? regards and TIA, dave

2 1

Cabal-install
by Andrew Coppin 11 Apr '10

11 Apr '10

OK, so apparently my Google skills are lacking. I can't find anything but the most terse documentation of the cabal-install tool online. Somewhere there surely must be something which explains how to control this thing. Anyway, can anybody tell me how I can change the default settings so that I get profiling libraries built by default, and Haddock documentation built by default? (I'm on Windows, in case that makes a difference...)

4 5