- Haskell-Cafe - Haskell.org

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

Exceeding OS limits for simultaneous socket connections
by Rob Stewart 07 Feb '12

07 Feb '12

Hi, I'm experiencing the "accept: resource exhausted (Too many open files)" exception when trying to use sockets in my Haskell program. The situation: - Around a dozen Linux machines running my Haskell program, transmitting thousands of messages to each other, sometimes within a small period of time. - I'm using the Network.Socket.ByteString.Lazy module to send and receive lazy bytestrings - The socket sent to the getMsg is bound and is listening, and is not closed until the program exits. getMsg is called in a loop to receive lazy bytestring from remote nodes. The socket is initialized with: sock <- Network.Socket.socket (addrFamily myAddr) Stream defaultProtocol bindSocket sock (addrAddress myAddr) listen sock 10 Here's the code: sendMsg :: Maybe HostName -> Int -> Lazy.ByteString -> IO () sendMsg dest sckt msg = do result <- try $ withSocketsDo $ do addrinfos <- getAddrInfo Nothing dest (Just (show sckt)) let serveraddr = head addrinfos sock <- socket (addrFamily serveraddr) Stream defaultProtocol connect sock (addrAddress serveraddr) sendAll sock msg sClose sock case result of Left (ex::IOException) -> return () -- permit send failure Right _ -> return () getMsg :: Socket -> IO Lazy.ByteString getMsg sock = do result <- try $ withSocketsDo $ do (conn, addr) <- accept sock getContents conn case result of Left (ex::IOException) -> putStrLn (show ex) >> getMsg sock Right msg -> return msg The current topology is a master/slave setup. For some programs that use these functions above, `sendMsg' is called thousands of times in quick succession on the remote nodes, where the destination of the `sendAll' function is the master node. Here's the maximum number of simultaneous sockets I am permitted to have open on my Linux machines: $ ulimit -n 1024 Indeed, when I experience the "accept: resource exhausted (Too many open files)" exception, I check the number of open sockets, which exceeds 1024, by looking at the contents of the directory: ls -lah /proc/<prod_id>/fd It is within the getContents function that, once the lazy bytestring is fully received, the socket is shutdown http://goo.gl/B6XcV : shutdown sock ShutdownReceive There seems to be no way of limiting the number of permitted connection requests from remote nodes. What I am perhaps looking for is a mailbox implementation on top of sockets, or another way to avoid this error. I am looking to scale up to 100's of nodes, where the possibility of more than 1024 simultaneous socket connections to one node is increased. Merely increasing the ulimit feels like a temporary measure. Part of the dilemma is that the `connect' call in `sendMsg' does not throw an error, despite the fact that it does indeed cause an error on the receiving node, by pushing the number of open connections to the same socket on the master node, beyond the 1024 limit permitted by the OS. Am I missing something? One would have thought such a problem occurs frequently with Haskell web servers and the like.. ? -- Rob Stewart

5 4

a variant of TDNR (was: Re: Some thoughts on Type-Directed Name Resolution)
by Evan Laforge 07 Feb '12

07 Feb '12

I brought up an idea on another thread, but it was a bit off subject and I think it got buried. Anyway, I'm curious to know if there are any obvious problems with this idea, or if it could be pursued further: It could be called Tagged Type Directed Name Resolution. The idea is a # prefix for identifiers. #f is a "type directed function". It requires the type of its argument to be monomorphic, and is desugared to M.f, where M is the module defining the type of 'f's argument. Everything else remains the same. Records wishing the same name must live in separate modules, but field access looks like: (#a . #b) record This works to set fields of a record as well. Let M.f be a function from a record to a lens focused on a certain field of that record. Now you can write: M.a :: M.Record -> Lens M.Record M.A set :: Lens record field -> record -> record val = set (#a 42) record which becomes: set (M.a record) 42 Or composed 'set ((#a.#b) record) 42' becomes 'set ((M.a . N.b) record) 42' An operator with convenient fixity should be able to remove the parens. As long as the compiler can figure out a monomorphic type expected by the input of #a then it shouldn't need type annotations. The thing I'm not sure about is if the ghc typechecker can do this. It would know that '#a' is a function 'alpha -> beta', then need to figure out what alpha is. Then once it has a monomorphic type for alpha, then it has to look up a symbol 'a' in the module defining that type, and only then does it know the type of beta. If #b.#a style composition is to work, then of course '#b' would have to hold off until the return type of '#a' has been resolved. I don't know how hard that would be, or it would even be possible. This idea is less powerful than other proposals because the #-decorated function must be able to statically determine a monomorphic type for its argument. So no structural types. And no records with the same field name in the same module. Personally that doesn't bother me much since I try to keep modules small, but perhaps that could be addressed in an orthogonal nested module feature. The '#' prefix would mess up people using that as an operator. I guess @ is free, right?

1 0

ghc-api Static Semantics?
by Christopher Brown 07 Feb '12

07 Feb '12

Hi, I was wondering if anyone could tell me if it's possible to get an AST from the ghc-api decorated with static-semantics? In particular, I am interested in use and bind locations for all names in the AST together with the module they are bound, etc. Looking through the online docs, there doesn't seem to be a way to do this. Even if I can tell from the AST where a variable is bound that would be enough, if this is by making all names unique and qualified that would be better than nothing. Hope someone can help, Chris.

4 10

Re: [Haskell-cafe] Rewrite this imperative in FP way
by Haisheng Wu 06 Feb '12

06 Feb '12

*d = [sum $ map (a !!) [i | i <- b, j <- c, i + j < 3, i + j == dIndex] | dIndex <- [0..3]] * This is cool. -Simon On Sun, Feb 5, 2012 at 5:07 PM, L Corbijn <aspergesoepje(a)gmail.com> wrote: > On Sun, Feb 5, 2012 at 7:28 AM, Haisheng Wu <freizl(a)gmail.com> wrote: > > a = [1,1,1,1] > > b = [0,1,2,3] > > d = [0,0,0,0] > > > > for i in b: > > for j in c: > > if (i+j)<3: > > d[i+j] += a[i] > > > > My just work implementation in Haskell > > http://hpaste.org/57452 > > > > Another people implementation in Haskell with Monad and it turns out > complex > > and very imperatively. > > http://hpaste.org/57358 > > > > Do you have any cool solution in FP way? > > > > Thanks. > > -Simon > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > There are several ways to make it nicer. > Without assumption on what lists a, b and c contain it can be written as > d = [sum $ map (a !!) [i | i <- b, j <- c, i + j < 3, i + j == dIndex] > | dIndex <- [0..3]] > > With the assumption that b and c are both [0..3] this can be 'improved' to > d = (take 3 . map sum . tail $ inits a) ++ replicate (4 - 3) 0 > This generates the first three values by the complicated expression > and then adds the extra zero's by using the replicate expression. This > works as the value of the i-th element of d is the sum over the first > i elements in a if i < 3 and 0 otherwise. A list of lists with the > first i elements is generated with 'tail $ inits a' which is then > summed and restricted to length 3. > An alternative for this is > d = (take 3 . snd $ mapAccumL (\acc ai -> (acc + ai, acc + ai)) 0 a) > ++ replicate (4 - 3) 0 > Where the summation and tail generating is done in the mapAccumL function. > > Greetings, > Lars > > P.S. Yes the replicate (4-3) 0 can be replaced by [0], but I wanted to > explicitly include the length (4) of the expected list. >

2 1

ANN: Updated OpenGL libraries
by Jason Dagit 06 Feb '12

06 Feb '12

Hello, I'm pleased to anounce a minor bug fix release of the OpenGL libraries. This release was prompted by issues and warnings when compiling with ghc-7.4.1. The following packages have been updated: * OpenGLRaw 1.2.0.0 * OpenGL 2.5.0.0 * GLURaw 1.2.0.0 * GLUT 2.3.0.0 Thanks goes out to: * Corey O'Connor * mgajda (github id) * #haskell-game and #haskell on freenode The changes include: * Removing a data type context * Exposing the GLfoo constructors from OpenGLRaw * Deriving Typeable instead of using the now deprecated mkTyCon * Added Eq constraint, necessary now that Num doesn't have an Eq constraint * Tighten constraints in cabal files * Conservative package version bump (X.Y.Z -> X.(Y+1).0) As usual, please submit pull requests and bug reports on github: https://github.com/haskell-opengl Thank you! Jason

2 1

Rewrite this imperative in FP way
by Haisheng Wu 06 Feb '12

06 Feb '12

a = [1,1,1,1] b = [0,1,2,3] d = [0,0,0,0] for i in b: for j in c: if (i+j)<3: d[i+j] += a[i] My just work implementation in Haskell http://hpaste.org/57452 Another people implementation in Haskell with Monad and it turns out complex and very imperatively. http://hpaste.org/57358 Do you have any cool solution in FP way? Thanks. -Simon

7 10

Problem resolving: Hangman
by Haisheng Wu 06 Feb '12

06 Feb '12

Though the problem I'd ask is not quiet related to haskell, I hope talent people here could provide some suggestions. The problem is not just solve the Hangman problem but solve it in sort of AI way. General idea is : 1. Randomly pick words, e.g. 20 from a predefined word list file. ( http://www.word-list.com/) 2. The application play hangman with each word till either WON or FAIL. NO human being interactive. 3. The expect result is the application be able to win the game at most of time before a certain max wrong guess, e.g. 5 Please let me where is a better place to ask such question and thank you so much in advance. -Simon

1 0