- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Too much inlining on text package
by wren ng thornton 08 Apr '12

08 Apr '12

On 3/16/12 12:22 PM, Aleksey Khudyakov wrote: > Disclaimer. I'm no expert in text internals. > > Because it's told to do so. This is an unfortunate feature of stream > fusion. It does eliminate intermediate data structures but it requires > that everything is inlined. There are ways of mitigating that, however. In particular, the standard style is to have things inline aggressively before stage 0 or 1, and then in the last stage to "inline" things back to an indirect call to the library. This is used ubiquitously in GHC's list fusion, and is essential for stream-fusion since the intermediate stream form is a pessimation when it can't partake in fusion. -- Live well, ~wren

6 8

using FlexibleInstances and OverlappingInstances
by TP 07 Apr '12

07 Apr '12

Hello, In a module I am writing, I would like to use FlexibleInstances and OverlappingInstances. But I get errors, so I am trying to reproduce the problems on a smaller program: -------------------------------------------- {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} data Foo = Foo Int deriving ( Show ) instance Show [Foo] where show [] = "[0]" show l = map show l main = do let l = [ Foo 1, Foo 2 ] print l -------------------------------------------- The first error I obtain is: -------------------------------------------- test_overlappinginstances.hs:7:19: Couldn't match expected type `Char' with actual type `[Char]' Expected type: a0 -> Char Actual type: a0 -> String In the first argument of `map', namely `show' In the expression: map show l -------------------------------------------- Where does this "Char" come from? How to solve this problem? The second error is: -------------------------------------------- test_overlappinginstances.hs:11:5: Overlapping instances for Show [Foo] arising from a use of `print' Matching instances: instance Show a => Show [a] -- Defined in GHC.Show instance [overlap ok] Show [Foo] -- Defined at test_overlappinginstances.hs:5:10-19 -------------------------------------------- The overlap is ok ("overlap ok" does not appear if not using the pragma OverlappingInstances), so it should work? Thanks in advance, TP

2 2

Conduits and Unix Pipes
by Clark Gaebel 07 Apr '12

07 Apr '12

Has anyone built an adapter between unix pipes and conduits? Something like: upipe2conduit :: String -> Conduit Char Char let someLines = "hello\nworld" nLines <- (read . runResourceT $ sourceList someLines $= upipe2conduit "wc -l" $$ consume) :: Integer If this has been done, is it on hackage? Thanks, - clark

2 2

Haskell integration with C/C++ (GSOC)
by Sutherland, Julian 07 Apr '12

07 Apr '12

Hey Guys, I'm Julian, I am reaching the end of my second year as a JMC (Joint Mathematics and Computer science) Student at Imperial College London and I'd like to apply to GSOC for a project involving Haskell and I just wanted to run my idea past the community. I've already talked about this on the haskell-soc IRC channel (I go by the pseudonym "julek"). What I would like to do is to improve the integration of C/C++ with Haskell, particularly in calling Haskell from C/C++. Currently ghc is able to generate stubs to export functions whose arguments are simple types such as CInts into C/C++. The stub generated is always in an extern "C" clause due to the fact that ghc does not as yet implement the C++ calling conventions as defined in the "The Haskell 98 Foreign Function Interface 1.0" (http://www.cse.unsw.edu.au/~chak/haskell/ffi/ffi.pdf) So a first step would be to implement this calling convention to bring it up to speed with the above referenced report. This shouldn't be too hard and mostly involves implementing C++ name mangling conventions. Next, I would like to extend the stub generation so as to be able to deal with more complex types. The type systems in C++ and Haskell have many analogous syntaxes that can be easily exploited to provide strong compatibility and interoperability between the two languages. For example a simple type such as: data Foo = A | B Could be implemented as an enum in C/C++: enum Foo {A, B}; More advanced types that take arguments such as: data Tree = Node Left Right | Leaf Could be converted to a struct in C/C++: struct Tree { struct Tree* left; struct Tree* right; }; Types that have functions that act on them such as: data IntContainer = IntContainer Int getInt :: IntContainer -> Int getInt (IntContainer a) = a could have these functions automatically converted to C/C++: struct IntContainer { int a; }; extern int getInt_hs(IntContainer a); This also opens up the possibility of exploiting C/C++ name mangling conventions, to allow the _hs postfix I'm suggesting here to be eliminated. Haskell classes: class Arithmetic a where (+) :: a -> a -> a (*) :: a -> a -> a (-) :: a -> a -> a (/) :: a -> a -> a could be implemented using C++ functions with virtual members: class Monad { public: virtual Monad add(Monad a, Monad b); virtual Monad mult(Monad a, Monad b) virtual Monad neg(Monad a, Monad b); virtual Monad div(Monad a, Monad b); } All types of single/multiple instancing (i.e. either directly or through requirements of instances) would be implemented using single/multiple inheritance. Obviously, this example is rather contrived due to the conversion of the function names. The fact that the rules that govern function naming in Haskell are much more permissive than those of C/C++ might cause compatibility issues. This can be worked around by implementing a similar syntax to that currently used for function imports by the FFI. E.g..: foreign export ccall "bind" >>= :: CInt -> CInt Similar to: foreign import ccall "f" func :: CInt -> CInt The latter is the current syntax for imports. The name given for the export would be checked for legality in the namespace of the target language. Alternatively this could be done in an automated manner using some naming conventions as well as operator polymorphism, but this would probably sacrifice ease of use. Finally polymorphic Haskell functions/types can be implemented in C++ using templates. I would like to extend ghc to implement enhanced C/C++ stub generation using the methods described above as well as to generate Haskell stubs which describe the Haskell CType equivalents of the Haskell types defined, functions for conversion between the two and function stubs to convert the types, run the Haskell function and convert back as required. On top of this I'd like to write C/C++ libraries for dealing with most of the standard Haskell types such as Maybe, Either, etc... Finally, I'd like to work on ironing out any bugs that remain in the RTS when it is used in "multilingual" situations, as well as improving it's performance in this situation. I found an example of such a bug, which I will test further before reporting it. It seems to be the opposite of the following bug: http://hackage.haskell.org/trac/ghc/ticket/5594 i.e. the stdout buffer isn't always correctly flushed when calling C/C++ in a program whose main is written in Haskell. For example, when running the code: main.hs: module Main where import Foreign.C.Types import System.IO foreign import ccall "inc" c_inc :: CInt -> CInt main :: IO () main = do putStr "Enter n: " -- hFlush stdout s <-getLine putStrLn . show . c_inc . read $ s inc.c: int inc(int i) __attribute__ ((const)); int inc(int i) { return i + 1; } Built with Makefile: all: gcc -c -o inc.o inc.c ghc --make -main-is Main main.hs inc.o -o test rm *.hi *.o The output comes out as: [julek@cryptid inc]$ ./test 2 Enter n: 3 But when the " hFlush stdout" line is commented back in, the output is: [julek@cryptid inc]$ ./test Enter n: 2 3 which is correct, but the extra line shouldn't be necessary. I am currently using ghc 7.4.1 which is the newest version, so this is a current bug. I have had a look for such a bug being reported and have found no such report. I'll look into this further before reporting it, but I am fairly certain this is a bug in the RTS. As part of this project, I would fix this bug (if it is still around when I start) as well as looking for other ones in this area. I think that extending ghc to the level required by "The Haskell 98 Foreign Function Interface 1.0" specification and above would reap significant benefit to the Haskell community. The improved integration into C/C++ would open the door for this to happen for several other languages and would make Haskell more widespread. Many Haskell beginners are daunted by the falsely perceived complexity of working with Haskell IO and monads, but love using the massive advantages that the paradigm gives in a non monadic context. Due to this, simplifying the interoperability between Haskell and C/C++ would enable many of these users to stick around for longer and perhaps encourage them to eventually look deeper into the language. This would make the size of the community grow and make the use of Haskell more widespread, potentially reaping benefits for the community at large. I believe this could be implemented within the time frame given for GSOC. Hope you like the ideas presented here and hopefully I'll be accepted into the Haskell summer of code! If anybody has any opinions on the implementability/usefulness of this and/or criticism of the idea, please inform me and I'll be happy to discuss it! Looking forward to hearing from you! Thanking you in advance. Kind regards, Julian Sutherland

7 7

Subscriber-only lists as Maintainer contacts of Cabal packges
by Joachim Breitner 07 Apr '12

07 Apr '12

Dear Cabal authors, if your package is team maintained and you put in a mailing list as the “Maintainer” contact of your package, that is in general a good thing. But if you do so, please make sure the list is not set to subscriber only; it is an unreasonable burden to subscribe for people who just want to send you one question, and possibly have to contact dozends of different package authors, e.g. as a distribution packager. Thanks, Joachim (Who really thinks that using the subscriber-only setting of mailman as an anti-spam-measure is an abuse of the feature, and that mailman should offer a “non-subscribers get a bounce that allows them to approve the message themselves“ feature which would give the same spam protection but much less hassle for the users.) -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

2 1

Testing Concurrent Programs
by satvik chauhan 06 Apr '12

06 Apr '12

How do you test concurrent programs in which you actually have to test over all possible interleaving schedules by the scheduler . Is this possible to do with quickcheck . Thanks , Satvik

1 0

Re: [Haskell-cafe] thread killed
by Gregory Collins 05 Apr '12

05 Apr '12

+haskell-cafe, oops On Thu, Apr 5, 2012 at 11:04 AM, Gregory Collins <greg(a)gregorycollins.net>wrote: > On Wed, Apr 4, 2012 at 10:09 PM, tsuraan <tsuraan(a)gmail.com> wrote: > >> > It's hard to rule Snap timeouts out; try building snap-core with the >> > "-fdebug" flag and running your app with "DEBUG=1", you'll get a spew of >> > debugging output from Snap on stderr. >> >> Heh, that was quite a spew. I normally get the exceptions tens of MB >> into files that are hundreds of MB, and I sometimes don't get them at >> all, so printing out the entire request body was a bit slow :) After >> commenting out some of the more talkative debug statements, I got the >> exception to happen, and it looks generally like this: >> > > I think I might know what your problem is. You're accepting file uploads > using handleMultipart, yes? Snap kills uploads that are going too slow, > otherwise you would be vulnerable to slowloris ( > http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening > here is that you're doing slow work inside the "Iteratee IO a" handler you > pass to that function, which makes Snap think the client is trickling bytes > to you. If that's the case, either finish the iteratee more quickly and do > the slow work back in the Snap handler (preferable), or disable the minimum > upload rate guard (although that's not recommended on a server talking to > the public internet.) > > G > -- > Gregory Collins <greg(a)gregorycollins.net> > -- Gregory Collins <greg(a)gregorycollins.net>

3 3

Re: [Haskell-cafe] Is this a correct explanation of FRP?
by Paul Liu 05 Apr '12

05 Apr '12

On Thu, Apr 5, 2012 at 4:30 AM, Ertugrul Söylemez <es(a)ertes.de> wrote: > Paul Liu <ninegua(a)gmail.com> wrote: > >> > This isn't switching. It's selection. If fullTime decides to be >> > productive, then alterTime acts like fullTime. Otherwise it acts >> > like halfTime. If both inhibit, then alterTime inhibits. This >> > allows for a much more algebraic description of reactive systems. >> >> AFRP can do this through ArrowChoice. Maybe you can explain the >> concept of "inhibition" in more detail? >> >> I fail to grasp why this is making switches obsolete. The idea of >> switch is to completely abandoning the old state. See the broken >> pendulum example. > > Some of this can be done through ArrowChoice. The difference is > comparable to why server parts form a monoid in Happstack. You don't > have to decide when a server part reaches a request. You let the server > part decide itself. In other words ArrowChoice forces you to deal with > events in the application itself: > > -- Library code: > x = x' > y = y' > > -- Application code: > proc inp -> do > r <- request -< () > if p r > then x -< inp > else y -< inp > > Signal inhibition allows the component wires themselves to deal with the > events and you as the higher level programmer to just stick the wires > together: > > -- Library code: > x = proc inp -> do requireReq -< (); x' -< inp > y = y' > > -- Application code: > x <|> y I'm curious as to how this plays out with the usual arrow compositions. How does x *** y behave when x inhibits? what about z >>> x? This cannot replace switching though, since the structure of your arrows cannot change dynamically, while with switches it can. -- Regards, Paul Liu

1 0

Fail-back monad
by Alberto G. Corona 05 Apr '12

05 Apr '12

Hi Haskellers. In my package MFlow [1] I program an entire web navigation in a single procedure. That happened in the good-old WASH web application framework. The problem is the back button in the Browser. To go back in the code to the previous interactions when the data input does not match the expected because the user pressed the back button one or more times, i came across this Monad specimen,: that solves the problem. data FailBack a = BackPoint a -- will go back to this point | NoBack a . -- Normal outcome | GoBack -- "exception":: must go to the last backPoint newtype BackT m a = BackT { runBackT :: m (FailBack a ) } -- this monad nas a loop instance Monad m => Monad (BackT m) where fail _ = BackT $ return GoBack return x = BackT . return $ NoBack x x >>= f = BackT $ loop where loop = do v <- runBackT x case v of NoBack y -> runBackT (f y) -- business as usual BackPoint y -> do z <- runBackT (f y) case z of GoBack -> loop -- if x was a backpoint, then redirects the flow to this backpoint other -> return other GoBack -> return GoBack --propagate the signal back This monad does not perform exploration of alternatives as is the case of MonadPlus instances. It does not perform the kind of backtracking of "nondeterministic" three navigations in the Prolog style. It just go back to the last point where the computation can restart again in a sequence of actions. In this example: liftBackPoint f= BackT $ f >>= \x -> return $ BackPoint x test= runBackT $ do lift $ print "will not return back here" liftBackPoint $ print "will return here" n2 <- lift $ getLine lift $ print "second input" n3 <- lift $ getLine if n3 == "back" then fail "" else lift $ print $ n2++n3 Whenever the second input is "back" The procedure will go back to where liftBackPoint is. Otherwise, it will return the concatenation of the two inputs. If the underlying monad is an instance of MonadState, it can transport the state that caused the failure to the backpoint. Are there something similar? May it be functionally equivalent to something simpler or with more grounds? I looked at some exception monads out there, but they did not seems to share the same idea [1] http://haskell-web.blogspot.com.es/2012/02/web-application-server-with-stat…

3 6

Re: [Haskell-cafe] Fail-back monad
by oleg＠okmij.org 05 Apr '12

05 Apr '12

Alberto G. Corona wrote about a monad to set a checkpoint and be able to repeatedly go to that checkpoint and re-execute the computations following the checkpoint. http://haskell-web.blogspot.com.es/2012/03/failback-monad.html The typical example is as follows. > test= runBackT $ do > lift $ print "will not return back here" > liftBackPoint $ print "will return here" > n2 <- lift $ getLine > lift $ print "second input" > n3 <- lift $ getLine > if n3 == "back" > then fail "" > else lift $ print $ n2++n3 Let us first consider a slightly simplified problem, with a different signature for liftBackPoint. Rather than writing do liftBackPoint $ print "will return here" other_computation we will write do backPoint $ do lift $ print "will return here" other_computation In that case, backPoint will be implemented with the Exception or Error monad. For example, > backPoint :: Monad m => > ErrorT SomeException m a -> ErrorT SomeException m a > backPoint m = catchError m handler > where > handler e | Just RestartMe <- fromException e = backPoint m > handler e = throwError e -- other errors propagate up We designate one exception RestartMe as initiating the restart from the checkpoint. Other exceptions will propagate as usual. Obviously, if we are in IO or some MonadIO, we could use the regular exception-handling facilities: throw/catch. Suppose however that marking of the checkpoint should be a single action rather that exception-like handling form. Then we need the continuation monad: > type BackT r m a = ContT r (ErrorT SomeException m) a > > backPointC :: Monad m => ContT e (ErrorT SomeException m) () > backPointC = ContT (\k -> backPoint (k ())) (we have re-used the earlier backPoint). Incidentally, the continuation monad will be faster than BackT in the original article. Attentive reader must have noticed that backPointC is shift in disguise. Here is the complete code. > {-# LANGUAGE DeriveDataTypeable #-} > > module BackT where > > import Control.Monad.Trans > import Control.Monad.Error > import Control.Monad.Cont > import Control.Exception > import Data.Typeable > > > data RestartMe = RestartMe deriving (Show, Typeable) > instance Exception RestartMe > instance Error SomeException > > -- Make a `restartable' exception > -- (restartable from the beginning, that is) > -- We redo the computation once we catch the exception RestartMe > -- Other exceptions propagate up as usual. > > -- First, we use ErrorT > > backPoint :: Monad m => > ErrorT SomeException m a -> ErrorT SomeException m a > backPoint m = catchError m handler > where > handler e | Just RestartMe <- fromException e = backPoint m > handler e = throwError e -- other errors propagate up > > test1 = runErrorT $ do > lift $ print "will not return back here" > backPoint $ do > lift $ print "will return here" > n2 <- lift $ getLine > lift $ print "second input" > n3 <- lift $ getLine > if n3 == "back" > then throwError (toException RestartMe) > else lift $ print $ n2++n3 > > -- Obviously we can use error handling in the IO monad... > > -- Suppose we don't want backPoint that takes monad as argument. > -- We wish backPoint that is a simple m () action. > > -- We will use Cont monad then: That is, we use Cont + Error Monad > -- We reuse the old backPoint > > type BackT r m a = ContT r (ErrorT SomeException m) a > > backPointC :: Monad m => ContT e (ErrorT SomeException m) () > backPointC = ContT (\k -> backPoint (k ())) > > abort e = ContT(\k -> e) > > test2 :: BackT r IO () > test2 = do > liftIO $ print "will not return back here" > backPointC -- This line differs > liftIO $ print "will return here" -- (and the indentation on here) > n2 <- liftIO $ getLine > liftIO $ print "second input" > n3 <- liftIO $ getLine > if n3 == "back" > then abort $ throwError (toException RestartMe) > else liftIO $ print $ n2++n3 > > test2r = runErrorT $ runContT test2 return

2 2