- Haskell-Cafe - Haskell.org

Haskell Engineer Needed for Machine Learning Group
by Charles Weitzer 04 Nov '15

04 Nov '15

Voleon Capital Management LP is a quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer with strong functional programming experience as soon as possible. Voleon's founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon's team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well. Here is our formal job description: ********************************************************** * Senior Software Engineer * Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems. The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, MIT, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm's offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, catered lunches, and competitive benefits packages. We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus. We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential. Required experience: - strong experience developing in a functional programming environment (Haskell, Erlang, others). - developing with C/C++/Python/Go in a Linux environment with a focus on performance, concurrency, and correctness. - working in TCP/IP networking, multi-threading, and server development. - working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.). - architecting and designing highly available systems. - architecting and designing large-scale data management infrastructure. - working in large codebases and building modular, manageable code. Preferred experience.: - debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc. - working with build and test automation tools. - working with well-defined change management processes. - diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc. - working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems. Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring. Benefits and compensation are highly competitive. ********************************************************** The above job description is just a starting point in terms of possible duties and seniority. We can be very flexible for the right person. If you are interested please apply on our website: http://voleon.com/apply/. If you have any questions or if you know of anyone who might be interested, let us know the best way to get in touch and we can discuss details. Thank you, Charles Weitzer Senior Recruiter Voleon Capital Management LP Office: 510.704.9870 x 7012 Mobile: (510) 558-9182 www.Voleon.com<http://www.voleon.com/>

11 19

Streaming a Conduit into a lazy list
by Jules Bean 04 Nov '15

04 Nov '15

Conduits seem like a popular and useful way to compose operations which consume and produce streams at various speeds. I hadn't used them before, so apologies for any obvious mistakes below. Conduits have lots of power in terms of how you can interleave monadic effects with the streaming; but I found that I had a stream with no effects at all and I wanted to convert it back into haskells more simplistic representation, lazy lists. This is probably a well-known trick, but I couldn't find how to do this from googling, so here is the solution I found in case it helps someone else: > {-# LANGUAGE DeriveDataTypeable, FlexibleContexts #-} > module Main where > > import Data.Conduit > import Control.Monad.Catch > import Control.Monad.Trans.Resource > import Control.Monad.Writer > import Control.Monad.Identity > import qualified Data.Conduit.List as CL > import Data.Typeable > > source123Error :: Monad m => Source m Int > source123Error = do > yield 1 > yield 2 > yield 3 > error "error" A source which produces some data and then hangs, to test lazy production. One solution which doesn't work is CL.consume (as its own docs say) - and instead this happens: *Main> :t runIdentity (source123Error $$ CL.consume) runIdentity (source123Error $$ CL.consume) :: [Int] *Main> runIdentity (source123Error $$ CL.consume) *** Exception: error But what we can do instead is push the data out via the Writer monad: > tellEverything :: MonadWriter [a] m => Sink a m () > tellEverything = awaitForever (\x -> tell [x]) *Main> :t source123Error $$ tellEverything source123Error $$ tellEverything :: MonadWriter [Int] m => m () *Main> snd $ runWriter (source123Error $$ tellEverything) [1,2,3*** Exception: error Success! A lazily produced list. If your output is of any size - and depending on the compositions pattern in your code - it may be much faster to use this version: > tellEveryEndo :: MonadWriter (Endo [a]) m => Sink a m () > tellEveryEndo = awaitForever (\x -> tell (Endo (x:))) *Main> ($[]) . appEndo . snd . runWriter $ (source123Error $$ tellOne) [1,2,3*** Exception: error I found a further case where the Conduit I was trying to run was pure but had a 'MonadThrow' constraint. You can use the same approach here, using the ExceptionT transformer to satisfy the MonadThrow constraint. > data MyError = MyError deriving (Show,Typeable) > instance Exception MyError > > source123Throw :: MonadThrow m => Source m Int > source123Throw = do > yield 1 > yield 2 > yield 3 > throwM MyError *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Error $$ tellEverything) [1,2,3*** Exception: error *Main Control.Monad.Except Control.Monad.Trans.Resource> snd . runWriter . runExceptionT $ (source123Throw $$ tellEverything) [1,2,3] An aside: I tried to measure the speed difference between the list-mappend and Endo-mappend approaches with the following code. count2N uses a binary-tree shaped recursion so it should be fairly bad for list-mappend with lots of long lists on the left. > count2N :: Monad m => Int -> Source m Int > count2N 0 = yield 0 > count2N n = count2N (n-1) >> count2N (n-1) > speedTest1 = print . length . snd . runWriter $ (count2N 24 $$ tellEverything) > speedTest2 = print . length . ($[]) . appEndo . snd . runWriter $ (count2N 24 $$ tellEveryEndo) With -O or -O2 I measure no speed difference between these, they both take a bit over 2 seconds. With no optimisation flag, speedTest2 is slower, 17 seconds vs 11 seconds. I'm quite surprised the Endo version isn't faster, it seems like something is rewriting those list appends? Cheers, Jules

1 0

Who's hiring, HS cafe edition Re: Haskell Engineer Needed for Machine Learning Group
by Carter Schonwald 04 Nov '15

04 Nov '15

My team at "megacorp " is hiring. Our main project right now is a domain specific sibling to Agda / idris that runs on top of strongly consistent replicated db that we're also in the process of iterating on. A colleague and I will be at Hac Phi this weekend, and we're also helping sponsor some of the catering costs. Talk to us if you're there! On Tuesday, November 3, 2015, Kim-Ee Yeoh <ky3(a)atamo.com> wrote: > > On Tue, Nov 3, 2015 at 6:24 PM, Adam Bergmark <adam(a)bergmark.nl > <javascript:_e(%7B%7D,'cvml','adam(a)bergmark.nl');>> wrote: > >> There are plenty of other places where people who don't want to work with >> haskell can look for employment. > > > You've lost me. Haskell-cafe is where people gather who want to work with > haskell. > > -- Kim-Ee >

2 2

Re: [Haskell-cafe] process package with compilers besides GHC
by Malcolm Wallace 03 Nov '15

03 Nov '15

Clean-up is generally good. I have not maintained any Haskell compiler for about 5 years now, so I think it is safe to say you can go ahead. nhc98 did indeed build the 'process' package as part of its library set, but most recently at version 1.0.1.4. Regards, Malcolm On 2 Nov 2015, at 16:21, Michael Snoyman wrote: > Forwarding directly to you, in case you're not reading the mailing lists. > > ---------- Forwarded message ---------- > From: Michael Snoyman <michael(a)snoyman.com> > Date: Mon, Nov 2, 2015 at 8:10 AM > Subject: process package with compilers besides GHC > To: Haskell Cafe <haskell-cafe(a)haskell.org>, libraries <libraries(a)haskell.org> > > > I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: > > 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers > 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC > > I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. > > * No pun intend >

1 0

remove account
by Richard Torruellas III 03 Nov '15

03 Nov '15

Can you remove the account associated with this email address. I did not realize passwords were stored in plain text before sending (I missed the small print on the page) Thanks

4 3

'Associative' order of calling
by Charles Durham 03 Nov '15

03 Nov '15

Is there a name for a fold that promises to call a function such that only an associative function will always return the same result. Or in other words, it has the property that it promises to call a function "associatively" on a set of data? Thanks! Charlie

12 46

process package with compilers besides GHC
by Michael Snoyman 03 Nov '15

03 Nov '15

I'm currently in the process* of a cleanup of the process package to reduce the usage of CPP conditionals in the code. Currently, as Simon PJ pointed out, it's quite difficult to follow the logic between Windows and POSIX platforms. During the cleanup, I've noticed that: 1. There's also quite a bit of complication around the __GLASGOW_HASKELL__ conditionals, intended to make the package compilable with other compilers 2. There seems to be no way that - in its current state - the package could be compilable with a compiler besides GHC I wanted to reach out and see if anyone is currently using the process package on a compiler besides GHC, and if so, get information on whether recent releases also work, and get some kind of automated testing in place to prevent regressions. If there are no such users, I'm likely to remove the (presumably non-working) conditionals. * No pun intend

3 2

ANN: dimensional-1.0 for statically checked physical dimensions
by Douglas McClean 03 Nov '15

03 Nov '15

Hello Haskellers, Björn Buckwalter and I are pleased to announce the release to Hackage of version 1.0 of the dimensional library, which statically tracks physical dimensions in Haskell code, as in the example below, preventing dimensional mistakes and requiring explicit documentation of units where raw values are exchanged with external systems. {-# LANGUAGE NoImplicitPrelude #-} module Example where import Numeric.Units.Dimensional.Prelude import Numeric.Units.Dimensional.NonSI -- a function that computes with dimensional values escapeVelocity :: (Floating a) => Mass a -> Length a -> Velocity a escapeVelocity m r = sqrt (two * g * m / r) where two = 2 *~ one g = 6.6720e-11 *~ (newton * meter ^ pos2 / kilo gram ^ pos2) >>> let re = 6372.792 *~ kilo meter >>> let me = 5.9742e24 *~ kilo gram >>> let ve = escapeVelocity me re >>> ve -- Show defaults to SI base units 11184.537332296259 m s^-1 >>> showIn (mile / hour) ve -- but we can show in other units "25019.09746845083 mi / h" >>> let vekph = ve /~ (kilo meter / hour) -- and extract raw values when needed 40264.33439626653 This version is a major upgrade, consolidating features from the classic dimensional package and the dimensional-tf package. It takes advantage of the DataKinds and ClosedTypeFamilies extensions in GHC 7.8 to offer even safer types with a nearly identical interface. Also included: - Units carry names which can be combined by multiplication, division, and (only where appropriate) application of metric prefixes. You can use expressions like: showIn (milli meter / second) timeTravelSpeed to get "39339.52 mm / s" - Exact conversion factors between units are available, even when those conversion factors involve multiples of pi, thanks to the exact-pi library - The dimensionally-polymorphic siUnit term represents the coherent SI base unit of any dimension, which can be convenient for wrapping and unwrapping quantities in some contexts. - Storable and Unbox instances for Quantity types are available thanks to the efforts of Alberto Valverde González. - The Numeric.Units.Dimensional.Dynamic module offers types for safely manipulating quantities and units whose dimensions are not known statically. Also available is a term-level representation for dimensions. - Several other missing instances have been provided, including Bounded, Data, and Typeable instances. - New commonly used US customary units have been added, including US fluid measures and the knot. We have several other development efforts underway, including a type-checker plugin inspired by Adam Gundry's work, and on which he has provided valuable advice, which we hope will lead to a clean library for dimensionally typed linear algebra. Comments and contributions are welcome at http://github.com/bjornbm/dimensional-dk. (The repository name is a carryover from the name we were using while developing this version.) One particularly welcome contribution would be assistance with developing a patch for GHC issue 10391 <https://ghc.haskell.org/trac/ghc/ticket/10391>. Cheers, Doug McClean

2 2

Why does disambiguation in RebindableSyntax sometimes requires type signatures?
by Jan Bracker 03 Nov '15

03 Nov '15

Hello, I am currently playing around with RebindableSyntax and having several bind/return/sequence functions in scope at the same time. I thought that it would be enough to just pick the right one to use in each do-block by using a "where" or a "let". Surprisingly, I get some type related issues I can only fix by adding in some type signatures, but I don't understand why these signatures are actually necessary. Here is my example program: {-# LANGUAGE RebindableSyntax #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} import Prelude import qualified Prelude as P import qualified Control.Effect as E import Control.Effect.State ifThenElse :: Bool -> a -> a -> a ifThenElse True t e = t ifThenElse False t e = e main :: IO () main = do return () where return = P.return data Tree = Leaf Int | Branch Tree Tree process :: Tree -> State '[ "flatten" :-> Bool :! 'R ] (Either Tree [Int]) process (Leaf i) = do flatten <- get (Var :: (Var "flatten")) if flatten then return $ Right [i] else return $ Left $ Leaf i where --(>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> State (E.Plus State f g) b (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return fail = E.fail process (Branch tl tr) = do eitherL <- process tl eitherR <- process tr case (eitherL, eitherR) of (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r where (>>=) :: (E.Inv State f g) => State f a -> (a -> State g b) -> State (E.Plus State f g) b (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return fail = E.fail The program uses the "effect-monad" package in version 0.6.1. 1) The type signatures in the "where" following each do-block of the "process" function are required. If I remove the type signature of the sequence functions I get a type error of the following nature: examples/effect/Test.hs:33:16: Could not deduce (E.Inv m0 f0 g0) arising from a use of ‘E.>>’ Relevant bindings include (>>) :: m0 f0 a -> m0 g0 b -> m0 (E.Plus m0 f0 g0) b (bound at examples/effect/Test.hs:33:9) In the expression: (E.>>) In an equation for ‘>>’: (>>) = (E.>>) In an equation for ‘process’: process (Leaf i) = do { flatten <- get (Var :: Var "flatten"); if flatten then return $ Right [...] else return $ Left $ Leaf i } where (>>=) = (E.>>=) (>>) = (E.>>) return = E.return fail = E.fail examples/effect/Test.hs:33:16: No instance for (E.Effect m0) arising from a use of ‘E.>>’ In the expression: (E.>>) In an equation for ‘>>’: (>>) = (E.>>) In an equation for ‘process’: process (Leaf i) = do { flatten <- get (Var :: Var "flatten"); if flatten then return $ Right [...] else return $ Left $ Leaf i } where (>>=) = (E.>>=) (>>) = (E.>>) return = E.return fail = E.fail Which I interpret as the inability to infer the "E.Effect" and "E.Inv" constraints that are implied by the use of "E.>>". But why can't those constraints be inferred correctly? Shouldn't a definition like "(>>) = (E.>>)" just propagate the type signature and specialize it as needed? 2) If I remove the type signature for the bind operation, I get the following type error: examples/effect/Test.hs:38:3: Couldn't match type ‘'["flatten" :-> (Bool :! 'R)]’ with ‘'[]’ Expected type: State '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) -> (Either Tree [Int] -> State '[] (Either Tree [Int])) -> State '[] (Either Tree [Int]) Actual type: State '["flatten" :-> (Bool :! 'R)] (Either Tree [Int]) -> (Either Tree [Int] -> State '[] (Either Tree [Int])) -> State (E.Plus State '["flatten" :-> (Bool :! 'R)] '[]) (Either Tree [Int]) In a stmt of a 'do' block: eitherR <- process tr In the expression: do { eitherL <- process tl; eitherR <- process tr; case (eitherL, eitherR) of { (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r } } In an equation for ‘process’: process (Branch tl tr) = do { eitherL <- process tl; eitherR <- process tr; case (eitherL, eitherR) of { (Left l, Left r) -> return $ Left $ Branch l r (Right l, Right r) -> return $ Right $ l ++ r } } where (>>=) = (E.>>=) (>>) :: (E.Inv State f g) => State f a -> State g b -> State (E.Plus State f g) b (>>) = (E.>>) return = E.return Which tells me that GHC is expecting the wrong type, but inferring the correct type. Again I don't see why this wrong type is expected and the right type is ignored. In either case, why does adding or removing the type signature for the local definitions make a difference at all? I suspect the issue has to do with the language extensions I enabled or the type-level computations that are done by the "effect-monad" package, but I cannot find a satisfying answer. Does anybody have a good explanation? I am working with GHC 7.10.2. Best, Jan

3 5

simple library for HTML form generation and processing
by Henning Thielemann 03 Nov '15

03 Nov '15

I posted the following already to web-devel(a)haskell.org but it seems to be relatively quiet there. ----- I like to get your advice about a simple library for web form generation and processing. So far I tried digestive-functors and reform. Both of them are advertised as being good in separating data from view. However, I am interested in one-off forms, that is, form data will always be rendered in one way. Thus I would like to save the efforts to combine data and view after they have been carefully separated. Formerly I have also used autolib-cgi: http://autolat.imn.htwk-leipzig.de/haddock/autolib-cgi-1.2/ It allowed me to generate the form and fetch and validate the data in one (monadic) go. The blaze-markup type MarkupM is a monad anyway, thus it seems to be straight-forward to use the monadic results for the data entered to the form. Is there a library that supports this style of web form handling?

1 0