- Haskell-Cafe - Haskell.org

help with multiparam type class
by gbwey9 17 Jul '14

17 Jul '14

Hi, Given any Event constructor, the 'conv' method passes in the field name to 'val' for each field. There is a Z instance for each Event arity. The call "conv E1::E1" works but requires that I explicitly specify the type. Is there any way to avoid that having to do that? For some reason 'conv' does not have enough information to know the type. Is there a way to do this with functional dependencies or type classes or something else? Here is the paste http://lpaste.net/107632 and here is the error: *Main> conv E1 <interactive>:3:1: No instance for (Z e0 (String -> E1)) arising from a use of `conv' The type variable `e0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance (Event e, Field a) => Z e (a -> e) -- Defined at testfamily.hs:28:10 instance Event e => Z e e -- Defined at testfamily.hs:20:10 Possible fix: add an instance declaration for (Z e0 (String -> E1)) In the expression: conv E1 In an equation for `it': it = conv E1 Thanks for any help, Grant

1 0

Feature Proposal: GHC Flag for implicit external Prelude
by Andrew Gibiansky 16 Jul '14

16 Jul '14

Hey all, I would like to propose a very minor flag to add to GHC. I would like GHC to have a --with-prelude flag, which would specify an alternate Prelude to use instead of the default Haskell prelude. This would have an effect similar to -XNoImplicitPrelude and an additional import MyNewPrelude in the source file. It might be a *little* different semantically, as a qualified import would disable the original implicit import, just like it does with the default Haskell prelude. The benefit this would have is that this would give alternate preludes a more first-class status. Instead of having to import an alternative prelude everywhere, you could just have a ghc-options: --with-prelude=... flag in your *.cabal file, and have a different prelude be used. This is important for my own work, as I highly prefer other preludes for my non-library development; I think this is a feature which will be very useful as Haskell develops and we try to figure out how to get rid of the warts in the current Prelude. In order to specify the actula module, I propose that you just pass the module name as the --with-prelude argument. You could thus invoke GHC like this: ghc --with-prelude=MyNewPrelude Main.hs Then, the same rules apply for figuring out which MyNewPrelude module you are referring to as if you had written a `import MyNewPrelude` statement in the file. I am willing to implement this for GHC if people agree that this is a useful flag (or at least agree that isn't not a *bad* idea). What are your thoughts on this proposal? -- Andrew

15 16

Looking for architecture/infrastructure advice on coping with thousands of concurrent clients
by Isak Hansen 16 Jul '14

16 Jul '14

Let's just imagine there aren't enough poker sites out there already and that it makes sense to build another one. Basically, there will be players connecting to one or more tables, most likely talking some kind of JSON based protocol with the server(s). #1 - What's a good way to set up and maintain compressed and encrypted connections from the clients to my cluster? I've been wanting to try out websockets, think that'll do? #2 - I'm new to Haskell and would appreciate thoughts on how to store and process game state. Imagine a plain application managing 1000 tables of poker, responding to player input (that magically appears) and timer events (e.g. folding players that fail to take action). What data structures and libraries should I be looking at here? Thoughts on concurrency and how I organize program flow? #3 - I'm thinking of ZMQ to wire components together. Would I be better off basing my cluster on Cloud Haskell or some other library for distributed work? Would love some quick pointers and feedback here, thanks in advance, Isak

7 7

[ANN](and feedback request) unagi-chan: Fast and scalable concurrent queues for x86, with a Chan-like API
by Brandon Simmons 15 Jul '14

15 Jul '14

I'm happy to finally release unagi-chan, an implementation of high-performance concurrent FIFO queues that have an API very similar to Control.Concurrent.Chan. You can see benchmarks and documentation here: http://hackage.haskell.org/package/unagi-chan If you have a moment (especially if you're on a non-x86 architecture) please take 10 minutes and run the tests with: $ cabal configure --enable-tests $ cabal build $ time ./dist/build/test/test Thanks to Ryan Newton for helping answer some low-level questions about his atomic-primops package which provides the CAS and fetch-and-add implementations that are the core of unagi-chan. REQUEST FOR FEEDBACK: would anyone be interested in any functionality like the following: - concurrent builder for Text, something like: new :: IO (InTextChan , Lazy.Text) write :: String -> InTextChan -> IO () - something similar for ByteString (is there a class for types convertable to ByteString?) - concurrent Text and/or ByteString readers, something like: reader :: Text -> IO TextReader takeText :: Int -> TextReader -> IO Text That's very sketchy, but I ask because I'm very close to that already with Unagi.Unboxed, and should be able to implement something like any of the above without too much trouble if it would be useful. Brandon http://brandon.si

3 4

extensible-transformers
by Ben Foppa 15 Jul '14

15 Jul '14

Hi cafe, I whipped up extensible-transformers ( https://github.com/RobotGymnast/extensible-transformers) this afternoon. The idea is to make Monad transformer code more like extensible-effects code (http://hackage.haskell.org/package/extensible-effects) Here's a sample: {-# LANGUAGE FlexibleContexts #-} module Main(main) where import Control.Monad.Trans.Flexible import Control.Monad.Trans.List import Control.Monad.Trans.State.Strict -- A flexible transformer stack built from existing transformers using `liftT`. bar :: (In (StateT Int) t, In ListT t) => t () bar = do n <- liftT get liftT $ ListT $ return $ replicate n () -- A flexible transformer stack built from existing transformers using `liftT`. baz :: In (StateT Int) t => t () baz = do liftT $ state $ \i -> ((), i + (1 :: Int)) -- A flexible transformer monad stack composed of two other flexible -- transformer monad stacks. foo :: (In (StateT Int) t, In ListT t) => t () foo = do bar baz main :: IO () main = do evalStateT (runListT foo) (1 :: Int) >>= putStrLn . show runListT (evalStateT foo (2 :: Int)) >>= putStrLn . show Any feedback on this? Does such a package already exist? Thanks, Ben

2 4

Doctest, quickcheck and typeclass
by Gautier DI FOLCO 14 Jul '14

14 Jul '14

Hi all, Is there a way, with doctest and quickcheck, to declare test at typeclass level (such as laws) and play them automatically at instance level? For example: -- | Convert from/to a List to/from an arbitrary data structure -- -- >>> prop > fromList . toList == id class Listable d where fromList :: [a] -> d a toList :: d a -> [a] And this test will be played for each instance. Thanks in advance for your help.

2 2

how to get ghci to load compiled modules in 7.8?
by Evan Laforge 14 Jul '14

14 Jul '14

I recently upgraded to 7.8.2 and I have a silly question. How do you get ghci to load compiled modules? When I try this: % cat >T.hs module T where x :: Int x = 42 % ghc -c -dynamic-too T.hs % s T.dyn_hi T.dyn_o T.hi T.hs T.o % ghci GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package filepath-1.3.0.2 ... linking ... done. Prelude> :l T [1 of 1] Compiling T ( T.hs, interpreted ) Ok, modules loaded: T. *T> It still loads the file interpreted, even though there is a .dyn_o present. What am I doing wrong? This is on x86-64 OS X.

1 1

How to walk under binders "for free" in 'bound'?
by Christiaan Baaij 14 Jul '14

14 Jul '14

Dear list, I'm trying to implement a small dependently typed language (based on [1]) using the generalised De Bruijn indices from the 'bound' library [2]. My main two datatypes are: > data Binder n a > = Lam {binder :: Name n a} > | Pi {binder :: Name n a} Representing my two types of binders, and: > data Term n a > = Var !a > | Universe Integer > | App !(Term n a) !(Term n a) > | Bind !(Binder n (Term n a)) !(Scope (Name n ()) (Term n) a) Representing terms. My problem lies with implementing type-inference for lambda-binders. Originally I started with: > inferType1 :: Eq a > => (a -> Term n a) -- ^ Context > -> Term n a -- ^ Term > -> Term n a -- ^ Inferred type > inferType1 ctx (Var a) = ctx a > inferType1 ctx (Bind (Lam b) s) = Bind (Pi b) s' > where > s' = toScope . inferType1 ctx' . fromScope $ s > ctx' = unvar bCtx fCtx > bCtx _ = fmap F $ extract b > fCtx = fmap F . ctx Where `toScope . inferType1 ctx' . fromScope` entails doing three subsequent traversals: - `fromScope` traverses the term in `s`, which quotients placements of 'F' distributing them to the leaves - `inferType ctx'` then traverses the result of `fromScope` to infer the type - `toScope` transforms the inferred type to a generalised De Bruijn form, requiring a full tree traversal. Also, the new context, `ctx'`, is defined in term of a traversal (fmap). Also note that, for every Scope I walk under, `ctx'` gets an additional traversal. Doing so many traversals seems/is expensive, so after some thinking I improved `inferType2` to: > inferType2 ctx (Bind (Lam b) s) = Bind (Pi b) s' > where > s' = Scope . inferType2 ctx' . unscope $ s > ctx' = unvar bCtx fCtx > bCtx _ = fmap (F . Var) . extract $ b > fCtx = fmap (F . Var) . inferType2 ctx Where the only traversal needed to get `s'` is done by `inferType ctx'`. However, the new context, `ctx'`, remains defined in terms of traversals (fmap). Again, note that, for every Scope I walk under, `ctx'` gets an additional traversal. I could get rid of the remaining traversals in `ctx'` by implementing `inferType3` as: > inferType3 ctx (Bind (Lam b) s) = Bind (Pi b) s' > where > s' = Scope . inferType3 ctx' . unscope $ s > ctx' = unvar bCtx fCtx > bCtx _ = Var . F . extract $ b > fCtx = Var . F . inferType3 ctx But if I do that I start running into problems elsewhere, because the context is now returning lifted expressions. These problems arise for example in `inferPi`, which checks if the type of a term is a pi-binder: > inferPi :: Eq a > => (Term n a -> Term n a) -- ^ Type inference function > -> Term n a > -> (n,Term n a,Scope (Name n ()) (Term n) a) > inferPi inferTy tm = case inferTy tm of > Bind (Pi b) s -> (name b, extract b, s) > t -> error "Function expected" Let's assume that I'm doing type inference for the term: > \(a:*).\(b:*).\(f:(pi(_:a).b).\(x:a).f x Where `*` is `Universe 0`. In the application `f x`, I need to determine if `f` has a pi-type. When using either `inferType` or `inferType2`, I will see that `f` has the shape: > Bind (Pi {binder = Name "_" (Var (F (Var (F (Var (F (Var (B (Name "a" ())))))))))}) > (Scope (Var (F (Var (F (Var (F (Var (B (Name "b" ())))))))))) And so, `inferPi` will have no problems seeing that `f` has a pi-type. However, when using `inferType3`, where the context, `ctx`, returns lifted expressions , `f` has the shape: > Var (F (Var (F (Bind (Pi {binder = Name "_" (Var (F (Var (B (Name "a" ())))))}) > (Scope (Var (F (Var (B (Name "b" ())))))))))) Now `inferPi` will have problems seeing that `f` has a pi-type, it will need to quotient out and distribute the (Var . F) first. The (non-)solution is to quotient and distribute on demand, by defining `inferType4`: > inferType4 :: Eq a > => (a -> Term n a) -- ^ Context > -> (Term n a -> Term n a) -- Quotient and distribute (Var . F) > -> Term n a -- ^ Term > -> Term n a -- ^ Inferred type > inferType4 ctx dist (Var a) = dist (ctx a) > inferType4 ctx dist (Bind (Lam b) s) = Bind (Pi b) s' > where > s' = Scope . inferType4 ctx' dist' . unscope $ s > ctx' = unvar bCtx fCtx > bCtx _ = Var . F . extract $ b > fCtx = Var . F . inferType4 ctx dist > > dist' (Var (F a)) = fmap (F . Var) . dist $ a > dist' e = e However, `inferType4` simply moves the traversal from one place to the other, giving us no improvement over `inferType2`. What we do however see is that, after having descended two Scopes, we would get a `dist'` function that does: > fmap (F . Var) . fmap (F . Var) . dist This gives me hope that instead of having to do two traversals using `fmap`, we could get one traversal of the form: > fmap (F . Var . F . Var) . dist According to the Functor law. I have absolutely no idea how to achieve this single traversal solution though. This leads me to have several, quite general, questions: - Is there a way to get a `dist` function, as defined in `inferType4`, that does a single traversal? - Would it be possible to even get rid of the traversal for the context `ctx`? Perhaps by approaching the `inferType` function completely differently? - Or is there simply no way to implement `inferType` for free (without traversals) using generalised De Bruijn indices? The complete code can be found at: https://gist.github.com/christiaanb/4e0fd1777aee927999aa Cheers, Christiaan Baaij [1] http://math.andrej.com/2012/11/08/how-to-implement-dependent-type-theory-i/ [2] http://hackage.haskell.org/package/bound-1.0.3

1 0

ANN: HacBerlin - Haskell Hackathon in Berlin, 26-28 Sep 2014
by Stefan Wehr 14 Jul '14

14 Jul '14

Dear Haskellers, another Haskell Hackathon is waiting for you! Where: Berlin, Germany When: Fri 26 - Sun 28 September 2014 Meet in Berlin, discuss, hack together and improve the Haskell infrastructure. We welcome all programmers interested in Haskell, beginners and experts! For all details, visit our wiki page (http://www.haskell.org/haskellwiki/HacBerlin2014) and make sure to register early. By the way: we are currently looking for one or two keynote talks. If you feel qualified, please let us know. Happy hacking, Stefan

1 0

book "Haskell Data Analysis Cookbook" by Nishant Shukla
by Vasili I. Galchin 14 Jul '14

14 Jul '14

I believe there is a non-thread safe code fragment in Chapter 1(page 15): import System.Directory (doesFileExist) ..... exist <- doesFileExist filename -- these two lines are non-thread safe .. yes?? to be thread-safe the above line and the following line would have to be together atomic .... input <- if exists then readFile filename else return "" ........... Vasili

3 4