- Haskell-Cafe - Haskell.org

Contributing to http-conduit
by Myles C. Maxfield 08 Feb '12

08 Feb '12

To: Michael Snoyman, author and maintainer of http-conduit CC: haskell-cafe Hello! I am interested in contributing to the http-conduit library. I've been using it for a little while and reading through its source, but have felt that it could be improved with two features: - Allowing the caller to know the final URL that ultimately resulted in the HTTP Source. Because httpRaw is not exported, the caller can't even re-implement the redirect-following code themselves. Ideally, the caller would be able to know not only the final URL, but also the entire chain of URLs that led to the final request. I was thinking that it would be even cooler if the caller could be notified of these redirects as they happen in another thread. There are a couple ways to implement this that I have been thinking about: - A straightforward way would be to add a [W.Ascii] to the type of Response, and getResponse can fill in this extra field. getResponse already knows about the Request so it can tell if the response should be gunzipped. - It would be nice for the caller to be able to know in real time what URLs the request is being redirected to. A possible way to do this would be for the 'http' function to take an extra argument of type (Maybe (Control.Concurrent.Chan W.Ascii)) which httpRaw can push URLs into. If the caller doesn't want to use this variable, they can simply pass Nothing. Otherwise, the caller can create an IO thread which reads the Chan until some termination condition is met (Perhaps this will change the type of the extra argument to (Maybe (Chan (Maybe W.Ascii)))). I like this solution, though I can see how it could be considered too heavyweight. - Making the redirection aware of cookies. There are redirects around the web where the first URL returns a Set-Cookie header and a 3xx code which redirects to another site that expects the cookie that the first HTTP transaction set. I propose to add an (IORef to a Data.Set of Cookies) to the Manager datatype, letting the Manager act as a cookie store as well as a repository of available TCP connections. httpRaw could deal with the cookie store. Network.HTTP.Types does not declare a Cookie datatype, so I would probably be adding one. I would probably take it directly from Network.HTTP.Cookie. I'd be happy to do both of these things, but I'm hoping for your input on how to go about this endeavor. Are these features even good to be pursuing? Should I be going about this entirely differently? Thanks, Myles C. Maxfield P.S. I'm curious about the lack of Network.URI throughout Network.HTTP.Conduit. Is there a particular design decision that led you to use raw ascii strings?

5 57

Loading a texture in OpenGL
by Clark Gaebel 08 Feb '12

08 Feb '12

Using the OpenGL package on Hackage, how do I load a texture from an array? In the red book[1], I see their code using glGenTextures and glBindTexture, but I can't find these in the documentation. Are there different functions I should be calling? [1] http://glprogramming.com/red/chapter09.html

6 14

-XPolyKinds and undefined arguments
by Douglas McClean 08 Feb '12

08 Feb '12

There are all sorts of useful functions that would otherwise require explicit type applications which we work around by passing undefined and ignoring its value. (See http://www.haskell.org/pipermail/libraries/2010-October/014742.html for a prior discussion of why this is, how the use of undefined for something that is perfectly well defined smells, and various suggestions about one day changing it.) Examples: Data.Typeable.typeOf, Foreign.Storable.sizeOf, etc. It seems to me that the new -XPolyKinds extension might provide a good long-term solution to statically insuring that arguments like this are always undefined and are never inspected. If we had a library definition: -- a kind-indexed family of empty types, Proxy :: AnyK -> * data Proxy a then we could write things that resemble type applications such as "sizeOf @Int64". Unlike the current approach, we'd be assured that nobody tries to use the value of such a proxy in any meaningful way, since you can't pattern match it or pass a "Proxy t" in a context expecting a "t". We'd have formal documentation of which parameters are in this value-is-unused-and-only-type-matters category (which might help us erase more often?). This is essentially the same Proxy type as in section 2.5 of the "Giving Haskell a Promotion" paper, except that by making it empty instead of isomorphic to () we end up with a type that only has one value (bottom) instead of two (Proxy and bottom), which should be a desirable property if we are trying to erase uses and forbid pattern matches and such, I think. Adding a syntax extension (or even some TH?) to make something like "@Int64" desugar to "undefined :: Proxy Int64" would eliminate the clutter/smell from the undefineds. Poly kinds allow us to use the same mechanism where the "undefined" parameter is a phantom type at a kind other than *. It seems to work nicely, and it cleaned up some of my code by unifying various proxy types I had made specialized at kinds like Bool. How would you compare this to some of the proposals in the 2010 thread? Would people still prefer their fantasy-Haskell-of-the-future to include full-blown support for explicit type applications instead? -Doug

2 1

FP activities and researchers in Warwickshire
by Ivan Perez 07 Feb '12

07 Feb '12

Hello, I recently moved to Kenilworth, Warwickshire, UK, and I'd like to know if there are meetings, talks, or any FP-related activities going on around here. I contacted somebody at Warwick University but, from what I understood, their Formal Methods group doesn't exist as such any longer and they don't carry out any coordinated, regular events regarding FP anymore. Cheers, Ivan

2 1

Evaluating parallel computations in order of finishing (approximately)
by Victor Miller 07 Feb '12

07 Feb '12

Suppose that we have a list [a] of computations that we want to evaluate in parallel. I would like to have something (probably a monad) which would return the list in order (roughly) of finishing: Say the monad is M. It would be something like the state monad, in that it would be implemented by a state transformer function. In this case the state would the set of computations to be evaluated. we might have a function include :: [a] -> M a () which would say that the monad's responsibility would be to evaluate all the members of a in parallel. We might also have a function strategy :: Strategy -> M a () which would indicate the parallel strategy to be used. The key thing would be function, completed, which produces a list of all the computations to be evaluated as a list roughly in order of completion. That is, if, inside the M monad we finished the do with completed then we would have a value M a [a] which would be the list in order of completion. Since everything is lazy we could ask for the head of the list, and it would be the first value whose computation finished. Does such a thing exist? Victor

3 2

network-2.3.0.10 compiled for ghc 7.4.1 windows
by Alberto G. Corona 07 Feb '12

07 Feb '12

Hi, After some pains, I compiled the package Network. sa_family_t is needed in network.Socket.Internal.asc and MinGW seems that it has no such variable defined. I share here the package with the compiled binaries included: http://skydrive.live.com/?cid=2F229EB748D4CBA3&id=2F229EB748D4CBA3%21105

3 8

Domain Specific Languages and better Error messages
by Victor Miller 07 Feb '12

07 Feb '12

This week, at work, I've been attending a workshop which is concerned with writing (actually rewriting) a domain specific language that we've been using. Although I've only known Haskell for four months, I can see that it's infected my brain, since I kept seeing Haskell solutions to all sorts of problems that were coming up. This DSL was written by two demon programmers in C. They've made many ad-hoc choices which look rather ugly to me. Even worse, they've invented a very primitive type system which would only be checked at run time. This looks particularly bad since the applications that we'd be running are very large parallel computations. I would like to make a try at writing an alternative based on Haskell, even though there's probably little chance that I could get it adopted (since no-one else here is familiar with functional programs, etc.). However, there is one issue that I'd like to address. I was looking at http://donsbot.wordpress.com/2007/03/10/practical-haskell-shell-scripting-w… gave a very nice presentation of a domain specific language for shell scripts. One point that was made that commands were implemented as functions, and privileged commands (i.e. those which needed root privileges) were produced a result with a separate type, so that type checking would give a compile time error if you didn't execute it via the priv combinator. But, the error messages given by ghc would be rather incomprehensible to someone who wasn't familiar with Haskell (and maybe even to someone who was!). Has anyone looked into something that would filter the error messages of put out by GHC and rewrite them into something more domain specific? Victor

1 0

Switching GHC Version
by HASHIMOTO, Yusaku 07 Feb '12

07 Feb '12

Hi, I wrote a simple shell function for switching GHC version on the system. It works only under Mac OSX, and only switch GHCs installed via .pkg installers. It's useful to experiment newer features without worrying breaking environment. GHC_BASE_DIR=/Library/Frameworks/GHC.framework/Versions/ ghcs () { VERSION=$1 sudo $GHC_BASE_DIR/$VERSION/Tools/create-links . /Library/Frameworks / } Usage: ~/work/today 08:21 ghcs 7.4.0.20111219-x86_64 Password: ~/work/today 08:21 ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.0.20111219 ~/work/today 08:21 ghcs 7.4.1-x86_64 ~/work/today 08:22 ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 Now I'm curious of better way to achieve this. This have limitations described above. Even it requires sudo because it modified symbolic links under `/usr`. Suggestions? -nwn

4 4

ANN: exists-0.1
by Gábor Lehel 07 Feb '12

07 Feb '12

There's a common pattern in Haskell of writing: data E where E :: C a => a -> E also written data E = forall a. C a => E a I recently uploaded a package to Hackage which uses the new ConstraintKinds extension to factor this pattern out into an Exists type parameterized on the constraint, and also for an Existential type class which can encompass these kind of types: http://hackage.haskell.org/package/exists My motivation was mostly to play with my new toys, if it turns out to be useful for anything that's a happy and unexpected bonus. Some interesting things I stumbled upon while writing it: - Did you know you can write useful existentials for Functor, Foldable, and Traversable? I sure didn't beforehand. - You can even write them for various Comonad classes, though in their case I don't think it's good for anything because you have no way to run them. - Surprisingly to me, the only * kinded class in the standardish libraries I found which is useful with existentials is Show, the * -> * kinded ones are more numerous. - I don't know if anyone's ever set out what the precise requirements are for a type class method to be useful with existentials. For example, any method which requires two arguments of the same type (the type in the class head) is clearly useless, because if you have two existentials there's no way to tell whether or not their contents were of the same type. I think this holds any time you have more than one value of the type among the method's parameters in any kind of way (even if it's e.g. a single parameter that's a list). If the type-from-the-class-head (is there a word for this?) is used in the method's parameters in a position where it's not the outermost type constructor of a type (i.e. it's a type argument), that's also no good, because there's no way to extract the type from the existential, you can only extract the value. On the other hand, in the method's return type it's fine if there are multiple values of the type-from-the-class-head (or if it's used as a type argument?), because (as long as the method also has an argument of the type) the type to put into the resulting existentials can be deduced to be the same as the one that was in the argument. But if the type-from-the-class-head is used *only* in the return type, then it's difficult to construct an existential out of the return value because the instance to use will be ambiguous. - There are a lot of ways you can write existentials, and the library only captures a small part of them. Multiparameter constraint? No go. More than one constraint? No go (though you can use Control.Constraint.Combine). More than one type/value stored? No go. Anything which doesn't exactly match the patterns data E where E :: C a => a -> E or data E a where E :: C f => f a -> E a? No go. I don't think there's any way to capture all of the possibilities in a finite amount of code. - ConstraintKinds lets you write class aliases as type synonyms, type Stringy a = (Show a, Eq a). The old way to do this is class (Show a, Eq a) => Stringy a; instance (Show a, Eq a) => Stringy a and requires UndecidableInstances. But if the alias has multiple parameters, the old way is still superior, because it can be partially applied where type synonyms can't. This is analogous to the situation with type synonyms versus newtype/data declarations, but interestingly, unlike data and newtypes, the class+instance method doesn't require you to do any manual wrapping and unwrapping, only the declaration itself is different. - One of the advantages FunctionalDependencies has over TypeFamilies is that type signatures using them tend to be more readable and concise than ones which have to write out explicit equality constraints. For example, foo :: MonadState s m => s -> m () is nicer than foo :: (MonadState m, State m ~ s) => s -> m (). But with equality superclass constraints (as of GHC 7.2), it's possible to translate from TF-form to FD-form (but not the reverse, as far as I know): class (MonadStateTF m, s ~ State m) => MonadStateFDish s m; instance (MonadStateTF m, s ~ State m) => MonadStateFDish s m. - PolyKinds only seems to be useful as long as there's no value-level representation of the polykinded type involved (it's only used as a phantom). As soon as you have to write 'a' for kind * and 'f a' for kind * -> *, you have to do the duplication manually. Is this right? - Writing this library really made me want to have a type-level "Ord instance" for constraints, more precisely a type-level is-implied-by operator. The typechecker clearly knows that Eq is-implied-by Ord, for example, and that Foo is-implied-by (Foo :&: Bar), but I have no way to ask it, I can only use (~). I tried implementing this with OverlappingInstances, but it seems to be fundamentally impossible because you really need a transitive case (instance (c :<=: d, d :<=: e) => c :<=: e) but the transitive case can't work. (My best understanding is that it's because the typechecker doesn't work forward, seeing "ah, c :<=: d and d :<=: e, therefore c :<=: e"; rather it works backwards, and sees that "c might be :<=: e, if there's a suitable d", but then it has no idea what to choose for d and goes into a loop.) Filing a feature request is in the plans. Er... </ul>. Cheers, ~g

4 10

ANNOUNCE MFlow-0.0.3 an Application Server for stateful web apps with statically typed widget combinators
by Alberto G. Corona 07 Feb '12

07 Feb '12

Hi Haskellers I I´m happy to announce the first version of MFlow http://hackage.haskell.org/package/MFlow MFlow permits the execution of web applications in a procedural form, that is, with multiple requests-response interactions in a single procedure. MFlow stores the execution state, manage timeouts, shutdown and restart the procedure on demand at the point of execution, even after server stop. These services are transparent for the programmer. The other aspect of MFlow are combinators for the definition of widgets and formlets that can be mixed freely with HTML formatting and produce statically typed values using the "traditional" formlet/applicative approach. There are bindings for the package XHtml, so no need to learn new paradigms/scripting/formatting.. Console and window oriented apps are possible. Out of te box serialization in files permits very rapid prototyping, but any backend can be used . MFlow (MessageFlow) was created initially as the user interface for the Workflow package . Currently is an alpha version. It has only basic authentication but I plan to inprove it for serious applications. I upload this version just in case anyone wants to play with it.

1 1