- Haskell-Cafe - Haskell.org

Rigid skolem type variable escaping scope
by Matthew Steele 24 Aug '12

24 Aug '12

While working on a project I have come across a new-to-me corner case of the type system that I don't think I understand, and I am hoping that someone here can enlighten me. Here's a minimal setup. Let's say I have some existing code like this: {-# LANGUAGE Rank2Types #-} class FooClass a where ... foo :: (forall a. (FooClass a) => a -> Int) -> Bool foo fn = ... Now I want to make a type alias for these (a -> Int) functions, and give myself a new way to call foo. I could do this: type IntFn a = a -> Int bar :: (forall a. (FooClass a) => IntFn a) -> Bool bar fn = foo fn This compiles just fine, as I would expect. But now let's say I want to change it to make IntFn a newtype: newtype IntFn a = IntFn (a -> Int) bar :: (forall a. (FooClass a) => IntFn a) -> Bool bar (IntFn fn) = foo fn I had expected this to compile too. But instead, I get an error like this one (using GHC 7.4.1): Couldn't match type `a0' with `a' because type variable `a' would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: FooClass a => a -> Int The following variables have types that mention a0 fn :: a0 -> Int (bound at <the line number that implements bar>) In the first argument of `foo', namely `fn' In the expression: foo fn In an equation for `bar': bar (IntFn fn) = foo fn I don't think I am grasping why adding the layer of newtype wrapping/unwrapping, without otherwise changing the types, introduces this problem. Seems to me like the newtype version would also be type-safe if GHC allowed it (am I wrong?), and I'm failing to understand why GHC can't allow it. Is there a simple explanation, or else some reading that someone could point me to? (-: Cheers, -Matt

6 9

explicit annotations on kind polymorphism for data types
by dude 24 Aug '12

24 Aug '12

Hello All: I'm working through Giving Haskell a Promotion. Section 2.4 presents an explicitly annotated data type declaration similar to the following: data EqRefl (a::X)(b::X) where Refl :: forall X. forall (a::X). EqRefl a a Has this been implemented in GHC 7.4.2? 7.8.3 in the GHC User Guide leads me to believe it has not. -- dude

3 4

Handle close on GC leading to wrong reported exit codes?
by Niklas Hambüchen 24 Aug '12

24 Aug '12

According to System.IO, handles are automatically closed once they are garbage-collected. This served me well for files so far, but for processes, it gives me a weird problem: If I don't prevent my stdErr handle from being garbage-collected, the exit code reported by getProcessExitCode is just wrong (for me, it's always ExitSuccess, no matter what the program does). I posted this into #haskell and some poeple could not reproduce it, so I wanted to ask the Cafe what happens if you run this and if you have an idea why it happens to me. Thank you Niklas The following code gives an example. (http://hpaste.org/73593) You can see the real exit code with "./test; echo $?". module Main where import Control.Concurrent (threadDelay) import System.Process import System.IO import System.Exit run :: FilePath -> [String] -> IO (Handle, Handle, Handle, ProcessHandle) run cmd args = do r@(i, o, e, p) <- runInteractiveProcess cmd args Nothing Nothing getProcessExitCode p >>= \me -> case me of Just (ExitFailure 127) -> error $ "command not found: " ++ show cmd _ -> do mapM_ (flip hSetBuffering LineBuffering) [i, o, e] return r main = do (i, o, e, p) <- run "./test" [] putStrLn "spawned" threadDelay 1100000 putStrLn "waited" print =<< getProcessExitCode p -- If you comment these away, the above always returns Just ExitSuccess -- print =<< hGetContents o -- print =<< hGetContents e {- test.c: #include <stdio.h> #include <unistd.h> int main(int argc, char const *argv[]) { sleep (1); printf ("some stdout\n"); fprintf (stderr, "some stderr\n"); fflush (stdout); fflush (stderr); return 2; } -}

1 0

model theory for type classes
by Patrick Browne 23 Aug '12

23 Aug '12

3 3

Bringing knowledge from Haskell to Java
by Thiago Negri 23 Aug '12

23 Aug '12

Hello everyone. I just posted about a fact that happens to everyone who codes in Java while learning Haskell. You end up trading knowledge from both sides. I'll appreciate if you could read and send me feedbacks: http://me-hunz.blogspot.com.br/2012/08/bringing-knowledge-from-haskell-to-j… Thanks, Thiago.

1 0

Re: [Haskell-cafe] regex-pcre is not working with UTF-8
by José Romildo Malaquias 23 Aug '12

23 Aug '12

On Tue, Aug 21, 2012 at 05:50:44PM -0300, José Romildo Malaquias wrote: > On Tue, Aug 21, 2012 at 04:05:28PM +0100, Chris Kuklewicz wrote: > > I do not have time to test this myself right now. But I will unravel my code a > > bit for you. > > > > > By November 2011 it worked without problems in my application. Now that > > > I have resumed developping the application, I have been faced with this > > > behaviour. As it used to work before, I believe it is a bug in > > > regex-pcre or libpcre. > > > > I believe it may be problem in String <-> ByteString conversion. The "base" > > library may have changed and your LOCALE information may be different or may be > > being used differently by "base". > > > > > The (temporary) workaround I found is to convert the strings to > > > byte-strings before matching, and then convert the results back to > > > strings. With byte-strings it works well. > > > > That is an excellent sign that it is your LOCALE settings being picked up by > > GHC's "base" package, see explanation below. [...] > I have written an application to test those things. There are 2 source > files: test.hs and seestr.c, which are attached. > > The test does the following: > > 1. shows the getForeignEncoding > > 2. uses a C function to show the characters from a String (using > withCString) and from a ByteString (using useAsCString) > > 3. matches a PCRE regular expression using String and ByteString > > The test is run twice, with different LANG settings, and its output > follows. [...] > As can be seen, regular expression matching does not work with > en_US.UTF-8. But it works with en_US.ISO-8859-1. > > The test shows that withCString is working as expected too. This > may suggest the problem is really with regex-pcre. The previous tests were run on an gentoo linux with ghc-7.4.1. I have also run the tests on Fedora 17 with ghc-7.0.4, which does not have the bug. The sources are attached. The tests output follows: $ LANG=en_US.ISO-8859-1 && ./test testing with String code: 70, char: p code: 61, char: a code: ffffffed, char: code: 73, char: s result: 4 testing with ByteString code: 70, char: p code: 61, char: a code: ffffffed, char: code: 73, char: s result: 4 regex : pa�s:(.*) text : pa�s:Brasil String match : [["pa\237s:Brasil","Brasil"]] ByteString match : [["pa\237s:Brasil","Brasil"]] $ LANG=en_US.UTF-8 && ./test testing with String code: 70, char: p code: 61, char: a code: ffffffed, char: code: 73, char: s result: 4 testing with ByteString code: 70, char: p code: 61, char: a code: ffffffed, char: code: 73, char: s result: 4 regex : país:(.*) text : país:Brasil String match : [["pa\237s:Brasil","Brasil"]] ByteString match : [["pa\237s:Brasil","Brasil"]] Clearly witchCString has changed from ghc-7.0.4 to ghc-7.4.1. It seems that With ghc-7.0.4 withCString does not obey the UTF-8 locale and generates a latin1 C string. Regards, Romildo

1 2

ANNOUNCE basic-prelude-0.3
by Dan Burton 23 Aug '12

23 Aug '12

We are pleased to announce a new release of basic-prelude. http://hackage.haskell.org/package/basic-prelude-0.3.0.0 We apparently weren't entirely clear about the original purpose of basic-prelude, and we got repeated feedback of the form "where are the list functions?" Somewhat in response to this, we decided to rename the BasicPrelude module to CorePrelude. This module is an *incomplete* prelude, and the goal of this module is to provide enhanced core Prelude functionality *without* making any controversial decisions. CorePrelude serves as the core of Michael's ClassyPrelude, my ModularPrelude, and now the new BasicPrelude module. (If you ever feel the need to create your own Prelude replacement, we encourage you to build it off of CorePrelude. If there is any reason that CorePrelude would not be well-suited to this purpose, then please let us know!) I believe that by using the same Core, it will be easier for these various Prelude replacements to play nice with each other. We created a new module, BasicPrelude (not to be confused with the old BasicPrelude), which *is* a fully-featured Prelude, emphasizing the use of Text and FilePath, while also providing most of the List functions that you know and love, with a few exceptions, as documented. BasicPrelude is among the simplest examples of how we intend CorePrelude to be used. The next time you are working on a hobby project, please try using BasicPrelude instead of regular Prelude, and let us know how it goes! {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE OverloadedStrings #-} import BasicPrelude -- Dan Burton

1 0

Rigid skolem type variable escaping scope
by oleg＠okmij.org 23 Aug '12

23 Aug '12

Matthew Steele asked why foo type-checks and bar doesn't: > class FooClass a where ... > > foo :: (forall a. (FooClass a) => a -> Int) -> Bool > foo fn = ... > > newtype IntFn a = IntFn (a -> Int) > > bar :: (forall a. (FooClass a) => IntFn a) -> Bool > bar (IntFn fn) = foo fn This and further questions become much simpler if we get a bit more explicit. Imagine we cannot write type signatures like those of foo and bar (no higher-ranked type signatures). But we can define higher-rank newtypes. Since we can't give foo the higher-rank signature, we must re-write it, introducing the auxiliary newtype FaI. > {-# LANGUAGE Rank2Types #-} > class FooClass a where m :: a > > instance FooClass Int where m = 10 > > newtype FaI = FaI{unFaI :: forall a. (FooClass a) => a -> Int} > foo :: FaI -> Bool > foo fn = ((unFaI fn)::(Char->Int)) m > 0 We cannot apply fn to a value: we must first remove the wrapper FaI (and instantiate the type using the explicit annotation -- otherwise the type-checker has no information how to select the FooClass instance). Let's try writing bar in this style. The first attempt > newtype IntFn a = IntFn (a -> Int) > newtype FaIntFn = FaIntFn{unFaIntFn:: forall a. FooClass a => IntFn a} > > bar :: FaIntFn -> Bool > bar (IntFn fn) = foo fn does not work: Couldn't match expected type `FaIntFn' with actual type `IntFn t0' In the pattern: IntFn fn Indeed, the argument of bar has the type FaIntFn rather than IntFn, so we cannot pattern-match on IntFn. We must first remove the IntFn wrapper. For example: > bar :: FaIntFn -> Bool > bar x = case unFaIntFn x of > IntFn fn -> foo fn That doesn't work for another reason: Couldn't match expected type `FaI' with actual type `a0 -> Int' In the first argument of `foo', namely `fn' In the expression: foo fn foo requires the argument of the type FaI, but fn is of the type a0->Int. To get the desired FaI, we have to apply the wrapper FaI: > bar :: FaIntFn -> Bool > bar x = case unFaIntFn x of > IntFn fn -> foo (FaI fn) And now we get the desired error message, which should become clear: Couldn't match type `a0' with `a' because type variable `a' would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: FooClass a => a -> Int The following variables have types that mention a0 fn :: a0 -> Int (bound at /tmp/h.hs:16:16) In the first argument of `FaI', namely `fn' In the first argument of `foo', namely `(FaI fn)' When we apply FaI to fn, the type-checker must ensure that fn is really polymorphic. That is, free type variable in fn's type do not occur elsewhere type environment: see the generalization rule in the HM type system. When we removed the wrapper unFaIntFn, we instantiated the quantified type variable a with some specific (but not yet determined) type a0. The variable fn receives the type fn:: a0 -> Int. To type-check FaI fn, the type checker should apply this rule G |- fn :: FooClass a0 => a0 -> Int ----------------------------------- G |- FaI fn :: FaI provided a0 does not occur in G. But it does occur: G has the binding for fn, with the type a0 -> Int, with the undesirable occurrence of a0. To solve the problem then, we somehow need to move this problematic binding fn out of G. That binding is introduced by the pattern-match. So, we should move the pattern-match under the application of FaI: > bar x = foo (FaI (case unFaIntFn x of IntFn fn -> fn)) giving us the solution already pointed out. > So my next question is: why does unpacking the newtype via pattern > matching suddenly limit it to a single monomorphic type? Because that's what removing wrappers like FaI does. There is no way around it. That monomorphic type can be later generalized again, if the side-condition for the generalization rule permits it. You might have already noticed that `FaI' is like big Lambda of System F, and unFaI is like System F type application. That's exactly what they are: http://okmij.org/ftp/Haskell/types.html#some-impredicativity My explanation is a restatement of the Simon Peyton-Jones explanation, in more concrete, Haskell terms.

1 0

Haskell/F#/Ocaml Developer Opportunity in Singapore
by mani maran 23 Aug '12

23 Aug '12

Hello Everyone, I am currently recruiting a Functional Programming Developer for one of the bank in Singapore. Anyone interested please contact me at +65-83991283 or please drop a note to me at manimaran_elumalai(a)kellyit.com.sgwith your contact details. Below are some skills my client is looking for... * Strong in a functional programming language (Haskell, OCaml, F#) * Additional useful languages: C++ / javascript * Maths skills useful. * Good communication skills. * Willingness to interact with traders & quants * 1st degree in Computer Science (preferably with some maths courses) * Post grad degree in Computer Science (Msc/Phd) * Publicly available code that can be reviewed. * No finance background required. Regards, Manimaran

1 0

Cloud Haskell real usage example
by Thiago Negri 22 Aug '12

22 Aug '12

Hello everyone. I'm taking my first steps in Cloud Haskell and got some unexpected behaviors. I used the code from Raspberry Pi in a Haskell Cloud [1] as a first example. Did try to switch the code to use Template Haskell with no luck, stick with the verbose style. I changed some of the code, from ProcessId-based messaging to typed channel to receive the Pong; using "startSlave" to start the worker nodes; and changed the master node to loop forever sending pings to the worker nodes. The unexpected behaviors: - Dropping a worker node while the master is running makes the master node to crash. - Master node do not see worker nodes started after the master process. In order to fix this, I tried to "findSlaves" at the start of the master process and send ping to only these ones, ignoring the list of NodeId enforced by the type signature of "startMaster". Now the master finds new slaves. The bad thing is that when I close one of the workers, the master process freezes. It simply stop doing anything. No more messages and no more Pings to other slaves. :( My view of Cloud Haskell usage would be something similar to this: a master node sending work to slaves; slave instances getting up or down based on demand. So, the master node should be slave-failure-proof and also find new slaves somehow. Am I misunderstanding the big picture of Cloud Haskell or doing anything wrong in the following code? Code (skipped imports and wiring stuff): -- newtype Ping = Ping (SendPort Pong) deriving (Typeable, Binary, Show) newtype Pong = Pong ProcessId deriving (Typeable, Binary, Show) worker :: Ping -> Process () worker (Ping sPong) = do wId <- getSelfPid say "Got a Ping!" sendChan sPong (Pong wId) master :: Backend -> [NodeId] -> Process () master backend _ = forever $ do workers <- findSlaves backend say $ "Slaves: " ++ show workers (sPong, rPong) <- newChan forM_ workers $ \w -> do say $ "Sending a Ping to " ++ (show w) ++ "..." spawn w (workerClosure (Ping sPong)) say $ "Waiting for reply from " ++ (show (length workers)) ++ " worker(s)" replicateM_ (length workers) $ do (Pong wId) <- receiveChan rPong say $ "Got back a Pong from " ++ (show $ processNodeId wId) ++ "!" (liftIO . threadDelay) 2000000 -- Wait a bit before return main = do prog <- getProgName args <- getArgs case args of ["master", host, port] -> do backend <- initializeBackend host port remoteTable startMaster backend (master backend) ["worker", host, port] -> do backend <- initializeBackend host port remoteTable startSlave backend _ -> putStrLn $ "usage: " ++ prog ++ " (master | worker) host port" -- [1] http://alenribic.com/writings/post/raspberry-pi-in-a-haskell-cloud

4 4