- Haskell-Cafe - Haskell.org

liboleg
by Suhail Shergill 30 Jan '14

30 Jan '14

hi, i would like to take over as maintainer of the liboleg package on hackage <http://hackage.haskell.org/package/liboleg>. i have gotten permission from the author (oleg) and the current maintainer (don) regarding the same via email. my hackage username is shergill. if there are no objections, could i be added to the maintainer group for liboleg and be granted upload rights? -- Suhail

3 4

Deprecating bytestring version 0.10.2.0
by Christian Laustsen 30 Jan '14

30 Jan '14

Hi everyone, Following some problems I experienced with Network.HTTP.Client.TLS, I found out the problem was specific to bytestring library version 0.10.2.0 and most likely fixed with this commit https://github.com/haskell/bytestring/commit/86df1f17b2332940df69f484182c5c… . The default version shipped with GHC 7.6.3 (0.10.0.2) works fine, and the version after 0.10.2.0 (that is, version 0.10.4.0) also works. It was suggested that I mention on here that I think we should deprecate the 0.10.2.0 version of bytestring specifically, since that is the one that introduces the problem, and there can be problems with having to specify specific versions of bytestring as a dependency when compiling across GHC versions. -- Christian // Tehnix

2 1

Builder vs Builder
by Andrew Cowie 30 Jan '14

30 Jan '14

Does anyone know whether blaze-builder is deprecated in favour of bytestring's new Builder module, or are they the same, or... I know Simon is the evil wizard cackling in his dank lair in both cases, and I do remember him saying he was trying to get his work "upstream" into bytestring, but I haven't heard anyone suggesting we should be using Data.ByteString.Lazy.Builder instead of Blaze.ByteString.Builder I can only imagine the integration with the allocation routines is much better now that it's in bytestring, but on the other hand it's hard to upgrade bytestring — it being so low in the stack — so perhaps the original blaze remains the right choice from a bugfix and stability perspective. Thoughts? AfC Sydney

6 9

GHC iOS ARMv7/ARMv7s fat support completed
by Luke Iannini 30 Jan '14

30 Jan '14

Hi folks, Happy to report that I've finished an approach to armv7/armv7s fat compilation, just in time for 7.8's imminent release. You'll find the necessary scripts here: https://github.com/ghc-ios/ghc-ios-scripts and the latest instructions for building GHC for iOS usage here: https://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS I've also added support for a perf-cross BuildFlavour, which will give a higher-performance and profiling-ready build that matches what we'll be putting together as the official 7.8 GHC iOS binaries: https://ghc.haskell.org/trac/ghc/ticket/8700 Cheers Luke

3 2

Is it safe to create global variables using unsafePerformIO?
by Alexander Alexeev 30 Jan '14

30 Jan '14

Hello! Lets consider the following code: import Control.Concurrent import Control.Concurrent.STM import System.IO.Unsafe (unsafePerformIO) {-# NOINLINE counter #-} counter :: TVar Int counter = unsafePerformIO $ newTVarIO 0 incCounter :: IO Int incCounter = do r <- atomically $ do t <- readTVar counter let t' = t + 1 writeTVar counter t' return t' return r main :: IO () main = do n1 <- incCounter print n1 n2 <- incCounter print n2 n3 <- incCounter print n3 This program prints: 1 2 3 So we have a "global variable". Do I right understand that newTVarIO creates TVar and RTS memoizes it since 'counter' function is pure? If it's true, could it happen that under some circumstances memoized value will be deleted from memory? Or Haskell keeps all memoized values forever? Another issue which I'm afraid of --- would the given code be safe in multithread application? For example, is it possible to encounter a race condition if two threads will try to create a new counter in the same time? Is there any other problems which should be taken in account? -- Best regards, Alexander Alexeev http://eax.me/

5 6

Lazy MWC Random?
by Sacha Sokoloski 29 Jan '14

29 Jan '14

Dear Haskellers, I'm in a situation where I'd like to generate an infinite list of random elements (basically, I'm simulating stochastic systems). I feel like MWC Random is the fastest RNG available, but when I try to pull the infinite list out of RandST, it obviously doesn't halt, because ST is strict. Someone posted a way around this in this stack overflow thread: https://stackoverflow.com/questions/16248600/parallel-computations-with-fas… Which would fix my problem. My question is though, why isn't ST.Lazy included as a PrimMonad instance anyway? The best answer I can come up with is that, since evaluating the Generator is time dependent, it's best to make it strict to make sure that one's program isn't tapping into /dev/random at arbitrary times. In this way the best stackoverflow solution is quite good. It requires one to strictly generate a Seed (since that's the only way to do it), but then converts the ST Monad to the Lazy version to Lazify everything else. However, my understanding of PrimMonad is simply that it's a class of low level monads i.e. IO and ST, so if there's some deeper reason to this, it's beyond me. Another question that I'm puzzling over: In the stack overflow solution, they also make an effort to only have to generate the seed a single time. Is this important performance wise? What I suppose this must hinge upon, is whether in saving an ST s Gen to a Seed, the conversion from an immutable to mutable array requires a copy or not. Is that the full extent of the complexity of this? Is the stackoverflow solution ultimately the most efficient? Is using MWC Random to generate infinite lists and efficient solution anyway? Thanks for any insight, - Sacha Sokoloski

3 3

New Functional Programming Job Opportunities
by Functional Jobs 29 Jan '14

29 Jan '14

Here are some functional programming job opportunities that were posted recently: Haskell Developer at Zalora http://functionaljobs.com/jobs/8678-haskell-developer-at-zalora Cheers, Sean Murphy FunctionalJobs.com

3 3

ANNOUNCE: GLUT 2.5.1.0
by Sven Panne 29 Jan '14

29 Jan '14

A new version of the GLUT package is available on Hackage, with the following new features: * Added support for left/right SHIFT/CTRL/ALT special keys. * Added skipStaleMotionEvents state flag, making it possible to skip all but the last motion event. * Added leaveFullScreen call. * Added support for position, application life cycle and multi-touch window callbacks. * Various object drawing improvements: * Added teacup and teaspoon objects, so we support the full Newell tea set now. * Added geometryVisualizeNormals state flag. * Added support for drawing objects via VBOs: vertexAttribCoord3, vertexAttribNormal, and vertexAttribTexCoord2. * Added support for menu fonts via new constructor MenuWithFont. Apart from glutInitErrorFunc and glutInitWarningFunc, which are not extremely useful IMHO, all freeglut features are now exposed on the Haskell side. Cheers, S.

2 1

To LLVM or not to LLVM...
by Ian Ross 29 Jan '14

29 Jan '14

A package I just released (arb-fft) gets about a 17% performance boost from using GHC's LLVM backend (on my machine at least). That seems a big enough gain that I put "-fllvm" into the ghc-options field in the Cabal file for the package. Unfortunately, that means the package won't install unless you have the LLVM tools installed. What's the best thing to do? Use the native code generator by default and add a Cabal flag to install using LLVM? Just take the "-fllvm" out and add a note to the Cabal file description to tell people to install using LLVM if they have it? A quick survey of packages on Hackage reveals only very few instances where the "-fllvm" flag appears in Cabal files, which makes me suspect that I'm doing it wrong. -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

3 4

Re: [Haskell-cafe] manage effects in a DSL
by oleg＠okmij.org 29 Jan '14

29 Jan '14

Lindsey Kuper wrote: > Lately I have gotten a lot of mileage out of thinking of monads as > embedded DSLs. This is in fact how Moggi suggested to view monads. I strongly suggest the remarkable paper Eugenio Moggi and Sonia Fagorzi A Monadic Multi-stage Metalanguage FOSSACS2003, pp. 358--374 http://www.disi.unige.it/person/MoggiE/ftp/fossacs03.pdf Here are two most salient quotations: An important principle of Haskell [PHA+ 97] is that pure functional evaluation (and all the optimization techniques that come with it) should not be corrupted by the addition of computational effects. In Haskell this separation has been achieved through the use of monads (like monadic IO and monadic state). When describing MMML we adopt this principle not only at the level of types, but also at the level of the operational semantics. In fact, we distinguish between simplification (described by local rewrite rules) and computation (that may cause side-effects). ... We outline a general pattern for specifying the operational semantics of monadic metalanguages, which distinguishes between transparent simplification and programmable computation. This is possible because in a monadic metalanguage there is a clear distinction between term-constructors for building terms of computational types, and the other term-constructors that are computationally irrelevant. For computationally relevant term-constructors we give an operational semantics that ensures the correct sequencing of computational effects, e.g. by adopting some well-established technique for specifying the operational semantics of programming languages (see [WF94]), while for computationally irrelevant term-constructors it suffices to give local simplification rules, that can be applied non-deterministically (because they are semantic preserving). I should point out a large design space of the embedded effectful DSL. First of all, an embedded DSL does not have to be monadic. Monad essentially corresponds to the let-form in embedded DSL: let_ :: Exp a -> (a -> Exp b) -> Exp b If we are implementing an offline DSL compiler, such a let_ form is inappropriate since it presupposes the interleaving of compilation and code generation. Indeed, according to the type of let_, the code for the body of let_ may differ depending on the result of Exp a (that is, the result of compiling and then running Exp a). Normally, we first generate code, _then_ we compile it and then we run it. Therefore, many DSLs will not have let_ form. Rather, they will have app :: Exp (a -> b) -> Exp a -> Exp b That is, DSL is an applicative rather than monadic. DSL may be even simpler, see for example, Sec 3.4 of http://research.microsoft.com/en-us/um/people/simonpj/papers/assoc-types/fu… for a simple DSL of communicating processes, which is not even applicative. (Its realization in Haskell may use monads, but this is an implementation detail. The full power of the implementation language is not exposed to the DSL programmer.) If the DSL is effectful, we may annotate the Exp type with a set of effects that an expression may perform. The most familiar example is the continuation monad Cont r a, which is annotated with the answer-type r. If Cont r a is polymorphic over r, the computation is pure. The type Cont Int a describes an impure computation, which may abort with an Int value, for example. If we continue on this road we quickly come to extensible-effects. It may happen that one annotation is not enough: we need two, to describe the (type)state of the computation before and after an operation. The simplest example is locking, with the type state showing the state of the lock (acquired or released). See Sec 5.2 Tracking state and control in a parameterised monad in the above typefun paper. The computational structure in question is not a monad -- it is more general than that. To summarize: the design space is large. The relevant computational structure is not necessary a monad: it could be less powerful or more powerful. One should resist jumping on the bandwagon of monads or free monads, which are so (over)hyped these days. It's best to first decide what sort of programs a DSL programmer should be able to write. The computational structure (monad or something else) will be clearer then.

1 0