January 2019 - Haskell-Cafe

Is there a recursion-scheme function to push info down one level?
by Robin Palotai 25 Jan '19

25 Jan '19

I came up with this utility function so I can access some info (`n`) from the parent's level: hoistWithUpper :: forall f g s t n . (Functor g) => (forall a. f a -> n) -> n -> (forall a. n -> f a -> g a) -> (n -> s -> t) -> Free f s -> Free g t hoistWithUpper fu n0 hoistFr hoistPure = go n0 where go :: n -> Free f s -> Free g t go n fr = case fr of Pure s -> Pure (hoistPure n s) Free f -> let n2 = fu f in Free (go n2 <$> (hoistFr n f :: g (Free f s))) I wonder if there's already a generalized form of this in recursion-schemes? Admittedly I'm fine with my helper so don't loose nights on this, but a little type golfing never hurts. There's a similar function `inherit` [1] in fixplate, but that operates on Fix (Mu there), not Free. With Free I guess the complication is managing the different way of maintaining annotation at the Free and Pure ctors. Practically I pass in (\n f -> ConstProd (Pair (Const n) f)) -- for hoistFr (\n u -> (n,u)) -- for hoistPure. where newtype ConstProd c f a = ConstProd (Product (Const c) f a) Thanks! Robin [1]: http://hackage.haskell.org/package/fixplate-0.1.7/docs/src/Data-Generics-Fi…

2 1

[Job] Senior back-end engineer at CentralApp
by Ashesh Ambasta 23 Jan '19

23 Jan '19

Hi everyone, This is my first post to Haskell-Cafe, so pardon me for any errors. I'm writing on behalf of my company, CentralApp, to pitch our job opening. <https://centralapp.workable.com/j/9AFEDD1C3C> We're a small company and I'm the sole back-end engineer so far, and we're investing heavily only in Haskell as our back-end language of choice. A large part of our codebase is in Scala, since that was the choice I made 4-5 years ago. Since then, I got introduced to Haskell and I'm only considering it as the programming language of choice for our back-end infrastructure. We have plenty of engineering challenges in the pipeline since we're undergoing good growth. We serve millions of API requests per week and we're scaling the product out further. We also don't have much in the way of technological debt going forward. Some of the recent /interesting/ Haskell projects we've introduced to our infrastructure are: _Lazy SSL engine based on LetsEncrypt _ This is a Haskell program that issues SSL certificates using LetsEncrypt by doing /on-the-fly/ and /lazy/ certificate issuance. This allows us to vastly simplify HTTPS for 100's of domains we serve. _API Gateway for request pipe-lining_ We're a service oriented architecture. This usually entails that most of our API requests need to be serviced by a combination of back-end services, instead of just one. A trivial way to solve it would be: say a request needs to be passed to service A and then to B, then the responses from each of these services need to be accumulated into one client response. A can first receive the client request, do something, and then make another request to B to do something else. A can then accumulate the response from B along with its own response, and reply to the client. As one might imagine, it becomes increasingly cumbersome and hard to debug this kind of setup. Not only do you introduce dependencies between services A and B, coupling them tighter than you'd like, but it gets really messy when you're going to deal with authentication, authorisation and rapid changes in either A or B. In the worst case, you end up with request cycles (e.g. B makes a request to A), which are requests that never terminate and can bring down large parts of your infrastructure. The other big elephant in the room is also service discovery in a distributed environment. What makes sure that service A can reach a healthy instance of service B? To address this growing pain, we wrote a Haskell API Gateway service, which we lovingly call Quasar (I'm a fan of astronomical names) which flattens request pipe-lining at the API gateway level. What it does is: 1. recognises the request (based on verb + path) 2. identifies the resources being affected in this request (based on the query params/ JSON body) 3. authenticates the user 4. authorises the user for access to the identified resources 5. performs a request based pipeline flow: which is just a traversal of a request-tree, where each node is an "operation" to be performed on an input and output. The input being the response of the previous operation, and the output being the response of this operation. We leverage Haskell's elegant abstraction over operations like this (STM in particular) to ensure the responses are accumulated and returned to the client. -- These are some of the ways we're using Haskell and how it has benefited us. Going forward, given we have a fairly large codebase in Scala, we'd embark on replacing a service with its Haskell equivalent given the amount of changes required in the Scala counterpart is larger than a threshold. All new services that go into our infrastructure, however, will be written in Haskell. So far, our staple libraries of choice are: * Squeal * Servant ... and the usual suspects (Wai/Warp, Aeson, etc.) -- Other than that, we're based in the heart of Brussels, which is a fantastic city to work in, and we will offer a competitive compensation. Free weekly Belgian beers are on us. If this sounds interesting, please feel free to apply on the link above (https://centralapp.workable.com/j/9AFEDD1C3C) Or if you have any questions, please ask! While we'd prefer colleagues based /in /Belgium, or willing to relocate, we're still open to considering all applications. Thanks! -- Best, Ashesh Ambasta Founder (Engineering) CentralApp SA

1 0

avoid to print empty string
by Damien Mattei 21 Jan '19

21 Jan '19

i have this in a Monad IO: forM_ fltrdNamesBDs $ \(name,bdSidonie,bdWDS) -> if (bdWDS /= bdSidonie) then putStrLn $ name ++ " " ++ (show (bdSidonie :: Maybe Float)) ++ " " ++ show (bdWDS :: Maybe Float) ++ " " ++ show (bdWDS == bdSidonie) else putStr "" is there a way to remove the silly putStr "" that output an empty string, i tried with when.... but as when return Nothing in case of False it fails to compile

3 2

ANN: network 3.0.0.0
by evan＠evan-borden.com 21 Jan '19

21 Jan '19

Announcing the release of network 3.0.0.0 http://hackage.haskell.org/package/network-3.0.0.0 Version 3.0.0.0 of network is less platform dependent, easier to build, easier to use correctly (yay no more String api), more extensible, and all around safer. Kazu Yamamoto and Tamar Christina deserve a special shout out, they put an exceptional amount of thought and work into this version and it really shows. Thanks to network's contributors for kicking the tires and continuing to keep quality high. Version 3.0.0.0 * Breaking change: the Network and Network.BSD are removed. Network.BSD is provided a new package: network-bsd. * Breaking change: the signatures are changed: ``` old fdSocket :: Socket -> CInt new fdSocket :: Socket -> IO CInt old mkSocket :: CInt -> Family -> SocketType -> ProtocolNumber -> SocketStatus -> IO Socket new mkSocket :: CInt Socket ``` * Breaking change: the deprecated APIs are removed: send, sendTo, recv, recvFrom, recvLen, htonl, ntohl, inet_addr, int_ntoa, bindSocket, sClose, SocketStatus, isConnected, isBound, isListening, isReadable, isWritable, sIsConnected, sIsBound, sIsListening, sIsReadable, sIsWritable, aNY_PORT, iNADDR_ANY, iN6ADDR_ANY, sOMAXCONN, sOL_SOCKET, sCM_RIGHTS, packSocketType, getPeerCred. * Breaking chage: SockAddrCan is removed from SockAddr. * Socket addresses are extendable with Network.Socket.Address. * "socket" is now asynchronous-exception-safe. [#336](https://github.com/haskell/network/pull/336) * "recvFrom" returns (0, addr) instead of throwing an error on EOF. [#360](https://github.com/haskell/network/pull/360) * All APIs are available on any platforms. * Build system is simplified. * Bug fixes. -- Evan Borden

7 7

building with stack, need some older versions for one library
by Dennis Raddle 20 Jan '19

20 Jan '19

I'm assembling a large stack project from various places. I just did "stack new", using the default resolver, copied in most of my code, and got it compiled. Except I'm stuck on one thing. I need to use the 'midi-0.2.2' library (reads/writes MIDI files). Its depends on older versions of the same of the core packages. What should I do now? Do I modify the LTS resolver to something older and then type "stack build" again? How can I find an appropriate resolver without hit-and-miss? Mike

3 2

Fragile GHC rank-2 type inference?
by Viktor Dukhovni 20 Jan '19

20 Jan '19

[ I am seeing somewhat subtle, and to me surprising, type-inference obstacles. I am presently using GHC 8.6.3. I don't know whether what I'm seeing is a feature or a bug. ] Given a function 'mkEnv' (a command-line option parser built using optparse-applicative) that returns a rank-2 type (via ApplicativeDo): {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE RecordWildCards #-} type Locker = forall a. IO a -> IO a data Env = Env { envLocker :: Locker, ... } mkEnv :: Locker -> Env mkEnv envLocker = do ... pure Env{..} in my complete program, the call to 'mkEnv' fails to compile, when called via: mkLockEnv :: IO Env mkLockEnv = do lock <- newMVar () let locker :: Locker locker = withMVar lock . const ... (mkEnv locker) -- Error message: * Couldn't match type ‘a’ with ‘a0’ ‘a’ is a rigid type variable bound by a type expected by the context: Locker at ... 132 Expected type: IO a -> IO a Actual type: IO a0 -> IO a0 * In the second argument of ‘mkEnv’, namely ‘locker’ * Relevant bindings include locker :: IO a0 -> IO a0 (bound at ...) | 132 | ... (mkEnv locker) | ^^^^^^ But after inlining the "locker" binding, the code compiles: mkLockEnv :: IO Env mkLockEnv = do lock <- newMVar () ... (mkEnv (withMVar lock . const)) Given "let-bound polymorphism": https://kseo.github.io/posts/2016-12-27-higher-rank-polymorphism.html I would not have expected the change to make a difference... In trying to simplify the code (attached) to understand the source of the problem, surprisingly, the simplified program compiles in either form. It is not apparent what facet of the larger program has a bearing on the construction of the rank-2 environment. The background is that some of my Haskell applications employ a shared lock to serialize writes to stdout from concurrent forkIO "threads". The lock is the usual: type Lock = MVar () withLock :: Lock -> IO a -> IO a withLock lock = withMVar lock . const I am however tempted to abstract away the concrete lock type, leaving just a polymorphic closure, which results in 'Env' having a rank-2 type: {-# LANGUAGE RankNTypes #-} data Env = Env { envLocker :: Locker, ... } type Locker = forall a. IO a -> IO a type EnvReader a = ReaderT Env IO a runLocked :: forall a. EnvReader a -> EnvReader a runLocked action = ask >>= \env@Env{..} -> liftIO $ envLocker $ runReaderT action env and this works in the attached sample program which builds and runs: $ echo "The answer to life the universe and everything is:" | ./locker --answer 42 The answer to life the universe and everything is: 42 but a larger program where a "runLocked" call is located deeper in the call chain, fails to compile except as described at the top of the message. -- Viktor.

2 7

Re: [Haskell-cafe] determine a type by universal property
by Olaf Klinke 19 Jan '19

19 Jan '19

Am 18.01.2019 um 13:00 schrieb haskell-cafe-request(a)haskell.org: > > Am Donnerstag, den 17.01.2019, 14:33 +0100 schrieb Olaf Klinke: >> I have two type signatures where I conjecture the only functors satisfying these >> are the Identity functor and functors of the form (,)s. Can anyone give hints as >> how to tackle a proof? >> >> Signature 1: What functors t admit a function >> forall f. Functor f => t (f a) -> f (t a) > > What about the functor > > data Void1 a > > It seems I can write > > g :: forall f. Functor f => t (f a) -> f (t a) > g x = case x of {} > > but Void1 is not the identity. (I guess it is `(,) Void`, if you want…) > > So if you allow the latter, let’s try a proof. Assume we have t, and > > g :: forall f. Functor f => t (f a) -> f (t a) > > We want to prove that there is an isomorphism from t to ((,) s) for > some type s. Define > > s = t () > > (because what else could it be.) Now we need functions > > f1 :: forall a. t a -> (t (), a) > f2 :: forall a. (t (), a) -> t a > > that are isomorphisms. Here is one implementation: > > f1 :: forall a. t a -> (t (), a) > f1 = swap . g . fmap (λx → (x,())) > > {- note: > x1 :: t a > x2 :: t ((,) a ()) > x2 = fmap (λx → (x,())) x1 > x3 :: (,) a (t ()) > x3 = g x2 > x4 :: (t (), a) > x4 = swap x3 > -} > > f2 :: forall a. (t (), a) -> t a > f2 (s, x) = x <$ s > > Now, are these isomorphisms? At this point I am not sure how to > proceed… probably invoking the free theorem of g? But even that will > not work nicely. Consider > > type T = (,) Integer > g :: forall f. Functor => T (f a) -> f (T a) > g (c, fx) = (,) (c + 1) <$> fx > > here we count the number of invocations of g. Surely with this g, > f2 . f1 cannot be the identity. > > > Cheers, > Joachim Hi Joachim, thanks a lot for the clue. I had not thought about the function \x -> (x,()). Your last example of g shows that if a g exists, it is not necessarily unique. Possibly I am missing a law for the function g that entails uniqueness. The identity law in Data.Traversable comes to mind and would rule out your last example. > Am 17.01.2019 um 15:42 schrieb Oleg Grenrus <oleg.grenrus(a)iki.fi>: > > I immediately see > > forall f a b. Functor f => (a -> f b) -> t a -> f (t b) indeed my type forall a f. Functor f => t (f a) -> f (t a) is interdefinable with your type above. > > which is Lens' (t a) a, agreed. > which is an iso > > exists e. (t a) ~ (e, a) I fail to follow this step. How does the Lens above imply this isomorphism? Is this a lens-specific thing or were you thinking along the same lines as Joachim? Let me give a bit of context. I was looking at generic functions that give rise to monad transformer instances of the form MonadFoo m => MonadFoo (BarT m) e.g. MonadExcept m => MonadExcept (StateT s m) One can factor StateT s into two adjoint functors, G = (s->) and F = (,)s. For defining the instance above generically it was necessary for the functor F to aadmit functions with the signatures in my original post. Then I conjectured that I actually had not generalized anything if the signatures forced my F to be of the form (,)s. Olaf

1 0

Re: [Haskell-cafe] ANN: LeanCheck v0.9.0 -- enumerative property testing
by Johannes Waldmann 19 Jan '19

19 Jan '19

Yes, leancheck is awesome. > When should I reach to enumerative testing? I think enumerative testing is best suited to algebraic data types. https://mail.haskell.org/pipermail/haskell-cafe/2018-September/129951.html In the past I had one standard example where random enumeration seems better than enumerative: (non)associativity of floating point ops (I like to use this in teaching) That's immediate in Quickcheck quickCheck $ \ x y z -> (x::Double) + (y+z) == (x+y)+z *** Failed! Falsifiable (after 3 tests and 3 shrinks): -0.3 -1.4266097805446862 -1.2543117889178947 You don't get to see a counterexample in Smallcheck Prelude Test.SmallCheck> smallCheck 5 $ \ x y z -> (x::Double) + (y+z) == (x+y)+z Completed 50653 tests without failure. To my surprise, we now have Prelude Test.LeanCheck> check $ \ x y z -> (x::Double) + (y+z) == (x+y)+z *** Failed! Falsifiable (after 87 tests): 0.0 Infinity (-Infinity) and I get the above (with "real" numbers) via Prelude Test.LeanCheck> checkFor 1000 $ \ x y z -> isInfinite x || isInfinite y || isInfinite z || (x::Double) + (y+z) == (x+y)+z *** Failed! Falsifiable (after 306 tests): 1.0 1.0 0.3333333333333333 Turns out the enumeration in Leancheck uses Rationals, while Smallcheck uses encodeFloat, which happens to produce only "nice" numbers (very few bits set) in the beginning. Prelude Test.LeanCheck> list 3 series :: [Double] [0.0,1.0,-1.0,2.0,0.5,-2.0,4.0,0.25,-0.5,-4.0,-0.25] Prelude Test.LeanCheck> take 12 $ list :: [Double] [0.0,1.0,-1.0,Infinity,0.5,2.0,-Infinity,-0.5,-2.0,0.3333333333333333,3.0,-0.3333333333333333] - J.W. PS: this post wouldn't be complete without me complaining that I cannot (easily) put the type annotation where it belongs - in the declaration of the name: Prelude Test.LeanCheck> check $ \ (x::Double) y z -> x + (y+z) == (x+y)+z <interactive>:22:12: error: Illegal type signature: ‘Double’ Type signatures are only allowed in patterns with ScopedTypeVariables Wat? TypeVariables? There aren't any!

5 6

ANN: LeanCheck v0.9.0 -- enumerative property testing
by Rudy Matela 18 Jan '19

18 Jan '19

Hello Haskell Café, A new version of LeanCheck is out (v0.9.0). LeanCheck is a property testing library (like QuickCheck) that tests values enumeratively. _Example._ Here's a simple example of LeanCheck in action showing that sorting is idempotent and list union is not commutative: > import Test.LeanCheck > import Data.List (sort, union) > check $ \xs -> sort (sort xs) == sort (xs::[Int]) +++ OK, passed 200 tests. > check $ \xs ys -> xs `union` ys == ys `union` (xs::[Int]) *** Failed! Falsifiable (after 4 tests): [] [0,0] LeanCheck works on all types that are instances of the Listable typeclass and is able to derive instances automatically using either Template Haskell or GHC.Generics. See [LeanCheck's Haddock documentation] for more details. _Whats new?_ Version 0.9.0 marks the addition of Listable typeclass instances for most standard Haskell types defined in the Haskell 2010 Language Report. This means you'll be able to test more functions without needing to define Listable instances yourself. [LeanCheck's changelog] provides more details. A separate package [leancheck-instances] provides instances for other types in the Haskell Platform. _Installing._ You can find LeanCheck on [Hackage] or [GitHub]. It is also tracked on [Stackage]. As usual, you can install it with: $ cabal install leancheck -- Rudy [Hackage]: https://hackage.haskell.org/package/leancheck [GitHub]: https://github.com/rudymatela/leancheck [Stackage]: https://www.stackage.org/package/leancheck [LeanCheck's changelog]: https://hackage.haskell.org/package/leancheck/changelog [LeanCheck's Haddock documentation]: https://hackage.haskell.org/package/leancheck/docs/Test-LeanCheck.html

2 2

determine a type by universal property
by Olaf Klinke 17 Jan '19

17 Jan '19

Dear cafe, We know how to derive free theorems from a type [1]. But there exist also examples where the existence of a certain function determines the type. I suppose this is a special case of a free theorem? For example, every functor that is right adjoint to another functor in Hask is representable in the sense of [2], that is, isomorphic to (r->) for some type r. [see * below] I have two type signatures where I conjecture the only functors satisfying these are the Identity functor and functors of the form (,)s. Can anyone give hints as how to tackle a proof? Signature 1: What functors t admit a function forall f. Functor f => t (f a) -> f (t a) Signature 2: What functors t admit a function t (t a -> b) -> a -> b Signature 1 is like Data.Traversable.sequence, only the Applicative constraint is weakened to Functor. It is somewhat dual to Distributive [3]. Signature 2 can, with some currying, for t = (,)s be transformed into Data.Function.flip. I am unable to comprehend the free theorem for signature 2. For signature 1, the Rank-2 type seems to cause trouble with free-theorems? Thanks, Olaf [1] https://hackage.haskell.org/package/free-theorems [2] https://hackage.haskell.org/package/adjunctions [3] https://hackage.haskell.org/package/distributive [*] The argument goes like this: (1) bottoms aside, every type x is isomorphic to () -> x. (2) f and g are adjoint if and only if (f a -> b) is isomorphic to (a -> g b). (3) g b is isomorphic to () -> g b by (1) with x = g b (4) () -> g b is isomorphic to f () -> b by (2) with a = (). (5) By (3) and (4), g b is isomorphic to f () -> b. We have found g = (r->) with r = f ().

3 2