News aggregator

Wrapping a C++ library

haskell-cafe - Mon, 01/26/2015 - 5:45pm
Hi there, There is a C++ library for which I'm working on an FFI wrapper. I've written a translation unit which defines several functions with an extern "C" API. Each of the functions does a little bit of C++ to operate the third party library, but the point is that I now have a C API that I can wrap with the FFI. The next thing I did was to try and get Cabal to compile this translation unit for me. I eventually hacked together a Setup.hs that I barely understand that calls gcc to compile the .cpp file and then calls `ar` to, um, well do whatever it is that ar does with .o files, make some sort of archive, or something. Next, I need to get my hsc file (in which I define some imported functions and some data types with Storable instances for shovelling data through the FFI) to compile. This file uses the hsc2hs #include macro to include the .h file of my translation unit. In turn, that .h includes some of the C++ header files from the third party, and eventually an STL header: vector. At this point, the co
Categories: Offsite Discussion

Comercial Haskell SIG

Haskell on Reddit - Mon, 01/26/2015 - 2:18pm
Categories: Incoming News

What on earth happened to whole program optimization

Haskell on Reddit - Mon, 01/26/2015 - 5:15am

I'm under the impression that this would be a big win for Haskell.

The only information I can find on it dates from the 00s and it seems to be all but abandoned. There was a post to the mailing list by SPJ saying that it shouldn't be too hard at all.

Now everybody's running a computer with 32gb+ of ram, what's the problem! is it just not that big of a win perhaps?

submitted by katieandjohn
[link] [20 comments]
Categories: Incoming News

NumberSieves status/maintenance

haskell-cafe - Mon, 01/26/2015 - 5:07am
This package was last updated in 2012, and the linked darcs repository is inaccessible. Do you intend to continue to maintain this package? If not, I would be happy to take over. Thanks, David Feuer
Categories: Offsite Discussion

ANN: Halcyon and Haskell on Heroku

General haskell list - Mon, 01/26/2015 - 3:25am
I’m happy to announce the initial public release of Halcyon, a system for installing Haskell apps and development tools. Halcyon stands on the shoulders of Cabal, and isn’t intended to replace it. Instead, consider Halcyon a proof-of-concept implementation of one possible future version of Cabal. - See the Halcyon examples for a demonstration of advanced Halcyon features. - Take a look at the Halcyon shootout for a comparison of build times and sizes across most Haskell web frameworks. - Read the Halcyon tutorial to learn how to develop a simple Haskell web app using Halcyon. While Halcyon isn’t a deployment system, it’s intended to be used for constructing deployment systems. I’m doubly happy to also announce Haskell on Heroku, a buildpack for deploying Haskell apps. - Read the Haskell on Heroku tutorial to learn how to deploy Haskell web apps to He
Categories: Incoming News

alpheccar's blog - Mon, 01/26/2015 - 3:16am
Categories: Offsite Blogs - Mon, 01/26/2015 - 3:11am
Categories: Offsite Blogs

ANN: deepseq-bounded 0.5 -> 0.6

haskell-cafe - Mon, 01/26/2015 - 1:40am
This may affect depending code. Please consult the distro changelog for specific information about how your code might be affected, or better yet, refer to and This is a transitional version of deepseq-bounded, with stability of the grammar expected in early March for version 0.7. This also causes major version bumps to the seqaid and leaky packages. To update everything, issue cabal update cabal install --reinstall --force-reinstalls seqaid which reinstalls the latest deepseq-bounded in passing. And also if you were to run "seqaid demo" it will use the updated version of leaky, so everything's up to date. The homepage for these projects starts at Kind Regards, Andrew _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Problem using Text.Regex on OS X.

libraries list - Mon, 01/26/2015 - 1:29am
Hi, I'm new to Haskell so I'm not sure how to solve this issue, yet. I was directed to this list from the IRC channel. Here's the issue: Using GHCi on OS X: Prelude Data.Text> :m Text.Regex Prelude Text.Regex> let r = mkRegex "_" ... eliding successful "Loading package ..." lines ... Loading package regex-compat-0.95.1 ... can't load .so/.DLL for: /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib (dlopen(/Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib, 9): Library not loaded: < at >rpath/libHSmtl- Referenced from: /Library/Haskell/ghc-7.8.3-x86_64/lib/regex-compat-0.95.1/libHSregex-compat-0.95.1-ghc7.8.3.dylib Reason: image not found) After running otool over the regex-compat dylib I can see lines like: ... Load command 24 cmd LC_RPATH cmdsize 80 path /Users/mark/Projects/hp/build/package/mtl- (offset 12) ... Which is not a path that is
Categories: Offsite Discussion

existentials + typeclasses, variants, and "open-world" generic heterogeneous data structures

Haskell on Reddit - Sun, 01/25/2015 - 7:28pm

Hi, r/haskell!

I've been working in Haskell for the past year or so, and have come to appreciate its beauty and simplicity more the more I use it. But I've come on a problem that has me a little stymied.

I'm building a DSL library that I want to be extensible, i.e., that the user can add new primitives to. The DSL library will allow "objects" to be in scope (held by a state object part of the DSL monad) and will provide combinators that allow for control flow in the DSL, such as if/else and looping. The objects have a set of well-defined operations: "predicate" (conditionalize the object down one branch of an if/else), "join" (join two branches of the object value at a control-flow merge point), and "generate" (generate the IR).

The problem comes in how to allow these objects to be stored in the core data structure (the environment state in the DSL monad). At its most basic level, it's a heterogeneous list (or map). I started by using an existential type for this, wrapping a typeclass:

data DSLState = DSLState { dslstateEnv :: Data.Map.Map ObjectID Object, ... } data Object = forall a. Object_ a class Object_ a where objID :: a -> ObjectID objPredicate :: a -> PredicateCondition -> a objJoin :: a -> a -> a objGenerate :: a -> (IR parameters and result)

But clearly this doesn't work because, e.g., the second argument of objJoin, and the return type of objPredicate and objJoin, are a, not Object. In the combinator implementations that need to invoke Predicate and Join, I have only Objects, and the existential hides the a type.

Moreover, I understand why the type system is giving me trouble here. There's no reason that the typechecker should trust that I pass the right object type as the second argument to objJoin. What if I try to join two objects of different types? The existential should disallow such an objJoin, for that reason.

The way I've gotten around this right now is to implement a Variant type (using unsafeCoerce and explicit integer type tags), and create a generic layer that uses only Variants (I also refactored out the typeclass+existential to a simple "curry the this pointer" manual dictionary-passing record, but I think that's orthogonal):

data Object = Object { objID :: ObjectID, objDataType :: VariantID, objData :: Variant, -- impl uses unsafeCoerce objPredicate :: PredicateCondition -> Object, objJoin :: Object -> Object, objGenerate :: (IR parameters and result) }

This is unnecessarily ugly, though, and requires boilerplate for every Object type. The standard existentials + typeclass example I see everywhere uses either UI widgets or shapes, but those problems never require another shape to appear on the RHS of any function type. Only the 'this' pointer (to borrow an OOP concept) is polymorphic.

One step in the right direction would be some sort of downcasting. E.g., a "downcast :: Object -> Maybe a" function. I attempted something like this with typeclasses but gave up after running into the non-overlapping restriction.

Another way out would be to give up on the "open world" requirement. If I could explicitly say "data Object = ObjectA ... | ObjectB ..." then I'd be done. But as this is a library, I'd rather leave it open to the user to add new object types.

Is there a standard solution to this? Or is there a name for the problem? Is there some trick I can use to reduce boilerplate?


submitted by cfallin
[link] [4 comments]
Categories: Incoming News

"Solve _ for _" expression: any study on this (or similar) ideas?

Haskell on Reddit - Sun, 01/25/2015 - 3:48pm

For a geometry library in Haskell, I had to write several ray-surface intersection functions such as:

intersectRayPlane :: Ray → Plane → [Point] intersectRaySphere :: Ray → Sphere → [Point] intersectRayTrig :: Ray → Trig → [Point] intersectRayBox :: Ray → Box → [Point] intersectRayCone :: Ray → Cone → [Point] (...)

Soon enough, I noticed that this job was mostly repetitive. In order to implement a new intersection function, I had to do, precisely, do the following tasks:

1. Write down the implicit equation for the surface (ex: `x^2 + y^2 + z^2 = r^2`, for a sphere). 2. Substitute the ray equation on them: `rayPoint t = pos + dir * t` 3. Solve for t. I will have an equation such as: `t = stuff`. 4. Write that on Haskell, in the form: `hitSphere (Ray pos dir) sphere = pos + dir * t where t = stuff`

For example, here is my hitPlane function:

hitPlane :: (Num a, Fractional a) => Ray a -> Plane a -> [V3 a] hitPlane (Ray rPos rDir) (Plane pPos pNorm) = [rPos + t *^ rDir] where t = dot (pPos - rPos) pNorm / dot rDir pNorm

Which was derived manually from this process. I started to wonder if I could - as with most manual labors - automatize this process on Haskell. Unfortunatelly, the answer is no, since it would need some kind of mechanism that is not available in Haskell:

solve equation for t

Which would work, more or less, like this:

> solve x * 2 == 6 for x 3 > solve [1, 2, 3] == [1, x * 2, 3] for x 1

With such a feature, I could easily implement my hitPlane function as:

hitPlane (Ray rPos rDir) (Plane rPos pNorm) = rPos + t *^ rDir where t = solve (isInsideSphere (rPos + rDir * t)) for t

Without having to do the math manually. Or, even better, I could actually write all of my intersection functions at once:

hitSurface (ImplicitSurface b) => Ray a -> b -> [Point] hitSurface (Ray rPos rDir) surface = rayPoint ray t where t = solve (isInsideSurface (rPos + rDir * t) surface) for t

Now, I completely understand this is absurd and undecidable in general. Netherless, programs such as Mathematica have similar solves which work perfectly, so, I wonder if something on those lines could be implemented, even if just as a limited compile-time macro with template haskell. Has this idea been studied already? What are the relevant papers/keywords?

submitted by SrPeixinho
[link] [18 comments]
Categories: Incoming News