- Haskell-Cafe - Haskell.org

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

Taking over maintainership of bitvec
by Andrew Lelechenko 17 Jan '19

17 Jan '19

I would like to take over `bitvec` package (https://hackage.haskell.org/package/bitvec) Unfortunately, the source code has not been updated for years and the test suite does not build nowadays. There are also known issues. I have prepared patches and tried to reach its maintainer James Cook (cced) by email, but have not heard back. There was a takeover of another James' package in October 2018 (https://mail.haskell.org/pipermail/libraries/2018-October/029062.html) In that case James appeared to be out of reach. -- Best regards, Andrew

2 1

HDBC database: error on accent table name
by Damien Mattei 16 Jan '19

16 Jan '19

Hi, i have this error: *** Exception: SqlError {seState = "", seNativeError = 1064, seErrorMsg = "You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'es where Nom = 'A 20'' at line 1"} when doing this : rows_coordonnees <- quickQuery' conn "select * from sidonie.Coordonnées where Nom = 'A 20'" [] it seems tha the tabel name: Coordonnées that contain an accent is causing serious problem to the parser at some point, if i use a table name without accent it works fine. i'm at the point to rename the table which have great impact on all the project build with many other languages (Scheme) that deal correctly the table name with accent. any idea? to make accent works with haskell. Regards, Damien -- Damien.Mattei(a)unice.fr, Damien.Mattei(a)oca.eu, UNS / OCA / CNRS

3 2

[Job] Soostone is hiring Haskell developers (NYC or remote)
by Ozgun Ataman 16 Jan '19

16 Jan '19

Dear Haskell Cafe, Soostone (http://www.soostone.com) is looking to hire for engineering positions in our Haskell development and operations team. At Soostone, you will be crafting and deploying products with various AI and optimization elements dealing with large quantities of data at their core to transform the way our clients tackle opportunities in consumer intelligence, marketing and pricing. We aim to develop high quality, reliable software while moving fast, being pragmatic and constantly improving our capabilities. Haskell usually makes this a little easier and we're big fans. We are located in New York City, but these are remote-friendly positions with little to no travel requirements. We will prefer candidates in North America, but will also consider qualified applications from elsewhere as long as the legal realities can be aligned. We are flexible in the work arrangement; depending on your jurisdiction and circumstances, these will either be direct hire or full-time contractor positions. Day-to-day, you will be interacting with technologies/components/libraries such as: - A relatively large Haskell codebase (500+ modules) spanning multiple applications and several reusable in-house libraries/packages - 200+ libraries from the Haskell ecosystem - Databases: PostgreSQL, Redis, DynamoDB - Analytics: Google BigQuery, tailor-made SQL EDSL/automation - A large suite of AWS and Google cloud solutions - APIs responding to millions of requests per day - Datasets spanning billions of rows …and typical activities will include: - Collaborative architecting and software design around new features - End-to-end implementation of entire components, from first line of code to the test suite - Interfacing with other languages, API services, foreign interfaces/functions as needed - Opportunities to work on all aspects of our platform, including both backend and frontend - Design/implementation of DSLs/EDSLs that supercharge tedious elements in the ecosystem - Abstract functionality into libraries and other reusable tools that ease the pain for other developers - Be on the lookout for opportunities to contribute back to the community through OSS work - Occasional trips to the land of Python, Typescript/JavaScript and Purescript for mission-specific needs Candidates of all skill/experience levels are invited to apply and will receive consideration, although these positions are likely not ideal for Haskell beginners or entry level developers without any experience. If you're interested, we encourage you to submit an application even if we've previously had conversations. If you have OSS contributions or a listing/linking of previous projects, please let us know as that's tremendously helpful to us in getting to know you. Please see the link below for more detail on the position and to submit an application. You can also reach out to us at jobs(a)soostone.com for any questions or ask here and we'll do our best to answer. Job Link: https://soostone-inc.workable.com/jobs/678589 The Soostone Team

1 0

looking for yesod-newsfeed example
by Johannes Waldmann 16 Jan '19

16 Jan '19

Dear Cafe, I want to add news feeds to a yesod application. Is there some example code that shows real-life usage of https://hackage.haskell.org/package/yesod-newsfeed ? Thanks - J.W.

2 1

How to set ghc options while building Setup.hs in cabal package?
by Magicloud Magiclouds 16 Jan '19

16 Jan '19

Hi, I have some code in Setup.hs in a cabalized project. I'd like them to be warning-free. But I could not find a way to set -Wall. I tried ghc-options in ~/.cabal/config. But seems like it did not kick in. ``` /bin/ghc --make -fbuilding-cabal-package -odir /home/shida/src/Personal/cairo-core/dist-newstyle/build/x86_64-linux/ghc-8.6.3/cairo-core-1.16.0/setup -hidir /home/shida/src/Personal/cairo-core/dist-newstyle/build/x86_64-linux/ghc-8.6.3/cairo-core-1.16.0/setup -i -i/home/shida/src/Personal/cairo-core/. -optP-include -optP/home/shida/src/Personal/cairo-core/dist-newstyle/build/x86_64-linux/ghc-8.6.3/cairo-core-1.16.0/setup/setup_macros.h -hide-all-packages -no-user-package-db -package-db /home/shida/.cabal/store/ghc-8.6.3/package.db -package-db /home/shida/src/Personal/cairo-core/dist-newstyle/packagedb/ghc-8.6.3 -package-id Cabal-2.4.0.1 -package-id base-4.12.0.0 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id haskell-src-exts-1.21.0-f3e84a9ee8883b0dcaaaaba712d74996854b441aa843a4dedc055c685debcfdb /home/shida/src/Personal/cairo-core/dist-newstyle/build/x86_64-linux/ghc-8.6.3/cairo-core-1.16.0/setup/setup.hs -o /home/shida/src/Personal/cairo-core/dist-newstyle/build/x86_64-linux/ghc-8.6.3/cairo-core-1.16.0/setup/setup -threaded ``` -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

2 2