# News aggregator

### Wrapping a C++ library

### I wrote another monad tutorial. Sorry.

### What on earth happened to whole program optimization

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]

### NumberSieves status/maintenance

### Monads in Dynamically-Typed Languages

### ANN: Halcyon and Haskell on Heroku

### alpheccar's blog

### http://conal.net/papers/icfp97/

### ANN: deepseq-bounded 0.5 -> 0.6

### Problem using Text.Regex on OS X.

### ANN: Halcyon and Haskell on Heroku

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

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?

Thanks!

submitted by cfallin[link] [4 comments]

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

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 pNormWhich 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 tWhich would work, more or less, like this:

> solve x * 2 == 6 for x 3 > solve [1, 2, 3] == [1, x * 2, 3] for x 1With 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 tWithout having to do the math manually. Or, even better, I could actually write **all of my intersection functions** at once:

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?

[link] [18 comments]