- Haskell-Cafe - Haskell.org

Breaking up long lines
by miketerrance 03 Apr '06

03 Apr '06

What is a good technique for breaking up long lines of code (for easier readability)? I have been inserting {- -} comments but there must be a better way. Something like \ in Python? Lycos email has 300 Megabytes of free storage... Get it now at mail.lycos.co.uk

4 3

Distributing monadic(?) functions across dyadic functions
by Jared Updike 03 Apr '06

03 Apr '06

Is there a common way (standard libs, higher order) to express the lambda part below? It's not particulary complicated but I think it is not higher-order enough > unionBy (\x y -> fst x == fst y) listOfPairs1 listOfPairs2 Something like "distribute fst (==)" where > distribute f op x y = f x `op` f y would leave > unionBy (distribute fst (==)) listOfPairs1 listOfPairs2 I imagine something involving Arrows and/or zip/curry/uncurry but I just can't see it. Is this a case of trying to make something more complicated than it is? Jared. -- http://www.updike.org/~jared/ reverse ")-:"

5 4

casting numerical types
by Matthias Fischmann 02 Apr '06

02 Apr '06

hi all, this should be a quick one (for now I would be happy with a "that's impossible", just want to make sure I don't miss anything). I want to compute the average from a list of arbitrary numerical element type. I wanted to do this: avg :: (Num a) => [a] -> a avg xs = sum (map fromNum xs) / (fromIntegral (length xs)) but it doesn't compile. All I could get to work is this: avg :: (Fractional a) => [a] -> a avg xs = sum xs / (fromIntegral (length xs)) avgI :: (Integral a) => [a] -> Float avgI = avg . map fromIntegral The two function names for the same thing are tolerable, but not very elegant. Is there another option? Thanks, Matthias

3 4

Parsec operator with letter problem
by Reto Kramer 01 Apr '06

01 Apr '06

I ran into the following problem with parsec's handling of operators. I hope someone on the list can show me a trick that resolve my current issue. At the end of this message is the full code for the reproducer. The language I'm parsing has infix operators of two forms. Some are special characters (e.g. a dot) and some are LaTeX like (e.g. \in). The letters that appear in the e.g. \in lead to problems with expression parsing. The following is what I expect: $ cat input1 a.b $ ./test input1 InfixExpr OP_Dot (Ident "a") (Ident "b") Good! Then I try (change the b to an n) $ cat input2 a.n $ ./test input2 Ident "a" OUTSCH! Changing the name of an identifier changed the expression! Then I try (add a space right after the dot) $ cat input3 a. n $ ./test input2 InfixExpr OP_Dot (Ident "a") (Ident "n") Good! What is going on? The 'n' is part of the "\in" operator (see reservedOpNames in test.hs program at the end of message) and confuses the parsec expression parser's ability to determine the end of expressions/identifiers. Adding a space right after the '.' operator resolves the issue, but that's not a suitable option for my users. Unfortunately I cannot remove the "\in" operator from the reservedOpNames list since otherwise "\in" is not recognized as an infix operator itself anymore. QUESTION: how can I get parsec's expression parser to work with infix operators of the form "\in"? Thanks, - Reto -- complete reproducer (test.hs) -- compile with: ghc -o test -package parsec test.hs module Main where import List (nub) import System (getArgs) import Text.ParserCombinators.Parsec import Text.ParserCombinators.Parsec.Expr import Text.ParserCombinators.Parsec.Language( emptyDef ) import qualified Text.ParserCombinators.Parsec.Token as P main :: IO () main = do{ args <- getArgs ; let fname = args !! 0 ; input <- readFile fname ; case parse spec fname input of Left err -> do{ putStr "parse error at " ; print err } Right x -> print x } data Op = OP_Dot | OP_In deriving (Show, Eq, Ord) data Expr = InfixExpr Op Expr Expr | Ident String | Number Integer deriving (Show, Eq, Ord) spec :: Parser Expr spec = do { whiteSpace ; e <- expression ; return e } expression :: Parser Expr expression = buildExpressionParser table basicExpr <?> "expression" op_infix :: Op -> Expr -> Expr -> Expr op_infix op a b = InfixExpr op a b table :: OperatorTable Char () Expr table = [ [binary "." (op_infix OP_Dot) AssocLeft] , [binary "\\in" (op_infix OP_In) AssocLeft] ] binary name fun assoc = Infix (do{ reservedOp name; return fun }) assoc basicExpr :: Parser Expr basicExpr = choice [ do{ i <- identifier ; return $ Ident i } ] lexer = P.makeTokenParser testdef testdef = emptyDef { P.identStart = letter <|> char '_' , P.identLetter = alphaNum <|> char '_' , P.opStart = oneOf $ nub $ map (\s -> head s) $ P.reservedOpNames testdef , P.opLetter = oneOf (concat (P.reservedOpNames testdef)) , P.reservedOpNames = [ ".", "\\in" ] } dot = P.dot lexer parens = P.parens lexer braces = P.braces lexer squares = P.squares lexer semiSep = P.semiSep lexer semiSep1 = P.semiSep1 lexer commaSep = P.commaSep lexer commaSep1 = P.commaSep1 lexer brackets = P.brackets lexer whiteSpace = P.whiteSpace lexer symbol = P.symbol lexer identifier = P.identifier lexer reserved = P.reserved lexer reservedOp = P.reservedOp lexer integer = P.integer lexer natural = P.natural lexer charLiteral = P.charLiteral lexer stringLiteral = P.stringLiteral lexer

2 3

haskell-mode indentation
by Kirill Kuvaldin 01 Apr '06

01 Apr '06

Hello there. Being an emacs-addicted person, I'm using haskell-mode for editing haskell code. But its default indentation rule doesn't seem to be correct. I mean when i type something like the code below, i've got the following indentation: doSomeStuff a b c = do somefunc a anotherfunc b onemorefunc c Whereas the correct indentation (in my opinion) is as follows: doSomeStuff a b c = do somefunc a anotherfunc b onemorefunc c Thus I need hitting TAB key 2 or 3 times to make indentation as mentioned above. Cheers, Kirill

2 1

Haskell's market
by Arnaud Bailly 01 Apr '06

01 Apr '06

Hello haskellers, I have been following this list's debates for a while and I am very enthusiastic about functional programming in general and haskell in particular. I am on the verge of starting a new sofware development project for a customer and I wonder whether or not Haskell would be the right tool to do the job. The project is a Point-of-sale distributed management system with the following (non-exhaustive) list of features : - rich GUI clients (on windows platform) to allow optimizing users input speed. There will about 50-60 'screens' and half as many 'reports', - local database with possibility to replicate and aggregate data, - central repository for aggregated data, aggregation should be synchronous but may fail due to poor network connectivity, - ease of deployment/update for new versions or modules, - secured (authenticated and encrypted) communications between nodes, - ... All in all, this project is quite typical of a small to medium sized business information system which is commonplace in software services. There are no stringent performance requirements nor extraordinary functional features or tricky algorithms, but the allocated time-frame (and money :-)) is quite small and I would like to optimize design and coding time to concentrate on user acceptance, deployment and testing issues. Java and object-oriented 'paradigm' is nearly hardwired in my brain so I expect quite a painful learning process to shift towards thinking in functional terms: I know quite well the theory but never did I put it to use on a significant scale. More profoundly, I am asking myself whether this investment will be really worthwhile for this kind of software. I have read with joy and amazement S.P.Jones "Composing contracts: an adventure in financial engineering" and P.Hudak's "An experiment in software prototyping productivity", but I have also followed the discussions with J.Reymont about its poker server tester and read "Haskell vs. Erlang, Reloaded". I am not asking anyone to 'sell' me Haskell, that would be like selling ice to a penguin as I am already convinced Haskell is really interesting in itself. And I am willing to do some investment in time and money to use Haskell at the expense of another simpler but less elegant solution (read Java :-)). I would be very happy to have some feedback about these issues, regards, -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr

6 8

Moving from Hugs to GHC and getting an error
by Adam Wyner 01 Apr '06

01 Apr '06

I developed some code in Hugs, but now am moving to GHC. I had used Hugs because I wanted to use the Trex module (extensible records), but this has not been as important as I had thought it would be. My modules run fine in Hugs, but I get an error message when I try to run my module in GHC. The message is: parse error on input `PropList' Otherwise the imported modules are interpreted. In the module, the type declarations are: type PropList = [String] type World = Int type Time = Int type SOA = Rec (properties :: PropList, time :: Time, world :: World) type DBSoas = [SOA] The error occurs just after PropList. Is there some basic difference between Hugs and GHC that I'm missing? Where can I get more information about Hugs GHC differences? Cheers, Adam

2 1

Newbie question: inferred type
by David Laffin 31 Mar '06

31 Mar '06

Hi, Newbie question. Given the inferred type for square, the inferred types for quad1, quad2 and quad3 are what I would expect. Is there a straightforward explanation (i.e. one that a newbie would understand) as to why the inferred type for quad4 is less general? Regards, dl -- GHC Interactive, version 6.4, for Haskell 98. Prelude> let square x = x * x Prelude> :t square square :: (Num a) => a -> a Prelude> let quad1 x = square (square x) Prelude> :t quad1 quad1 :: (Num a) => a -> a Prelude> let quad2 x = square $ square x Prelude> :t quad2 quad2 :: (Num a) => a -> a Prelude> let quad3 x = (square . square) x Prelude> :t quad3 quad3 :: (Num a) => a -> a Prelude> let quad4 = square . square Prelude> :t quad4 quad4 :: Integer -> Integer ___________________________________________________________ Yahoo! Photos NEW, now offering a quality print service from just 8p a photo http://uk.photos.yahoo.com

3 2

multiple computations, same input
by Greg Fitzgerald 31 Mar '06

31 Mar '06

How do I perform multiple computations on a long lazy list without introducing a space leak? Doing a single computation like this works great: f = show . filter (> 1) But if I do something like this: f lst = show (filter (> 1) lst, filter (> 2) lst) then it looks like GHC won't garbage collect list elements until the first filter has completely finished, and the second filter has iterated over them. Is there an easy way to feed each element into both functions, instead of feeding all elements to one function, and then all to the next? Thanks, Greg

11 20

Wrapping the IO monad to get safe, self-describing imperative APIs
by Brian Hulley 31 Mar '06

31 Mar '06

Hi - In a discussion started on the GHC mailing list http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009923.h… I discovered an idea for typing imperative API functions that may be of interest to other people, and which makes use of Haskell's type system to achieve a level of self-description and static bad-usage detection impossible in C/C++ APIs. A nicely formatted (by trac) description of the advantages and how to write such APIs is available at http://hackage.haskell.org/trac/ghc/ticket/736 (a feature request I submitted to the GHC team to make it easier to write such APIs) and the plain text is included at the end of this post. The basic idea is that different monads, which are just newtypes of the IO monad, can be used to prevent API functions being called in the wrong context. For example, consider the following C function which implements a render callback using a simplified version of DirectX to draw a square on the screen: void Render(int width, int height){ Clear(); BeginScene(); DrawSquare(); EndScene(); } In the C code, the fact that DrawSquare() can only be called between Begin/EndScene, and the fact that Clear(), BeginScene(), EndScene() can only be called in a render callback (as opposed to a keypress callback for example) are completely implicit, and must be borne in mind by the user who has to wade through heaps of documentation to guess at this understanding. By using different monads in Haskell, the above function could be written as follows: newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO) newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO) type RenderCallback = Int -> Int -> RenderM () onRender :: RenderCallback -> IO () clear :: RenderM () scene :: DrawM () -> RenderM () drawSquare :: DrawM () render :: RenderCallback render w h = do clear scene $ do drawSquare making it impossible to call drawSquare in any situation that the API did not intend, and also making it easy to see that in order to draw something, the drawing will need to be an argument of some function which makes use of DrawM () eg scene, which in turn needs to be an arg of some function which takes a RenderM () thus leading from inside out: drawSquare --> scene --> RenderCallback --> onRender. A consequence of all this is that it would be necessary (to completey enforce API correct usage) to have an extra optional entry point for Haskell programs, to prevent APIs being re-started by lifting their init functions into a callback monad (more details at the end of this post and the trac report). Regards, Brian. #736: Allowing any newtype of the IO monad to be used in FFI and extra optional entry point ------------------------------------+--------------------------------------- Reporter: brianh(a)metamilk.com | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.4.1 Severity: normal | Keywords: FFI foreign monad entry point Os: Multiple | Difficulty: Unknown Architecture: Multiple | ------------------------------------+--------------------------------------- Hi - When designing an API it is desirable to be able to encode the correct usage patterns for functions in the API in the type of the functions themselves, rather than relying on the user understanding the documentation and having to use runtime checks to ensure correct usage. Consider the following callback which uses a typical C API (DirectX) to draw something to the screen: {{{ void Render(int width, int height){ Clear(); BeginScene(); DrawSquare(); EndScene(); } }}} In Haskell with the FFI at present, we can define an equivalent API and use it as follows: {{{ type RenderCallback = Int -> Int -> IO () clear :: IO () scene :: IO () -> IO () drawSquare :: IO () onRender :: RenderCallback -> IO () runGraphicsWindow :: IO () -> IO () render :: RenderCallback render w h = do clear scene $ do drawSquare main = runGraphicsWindow $ do onRender render }}} This is all very well, but just like the C equivalent, it doesn't encode the fact that drawSquare can only be called between BeginScene and EndScene. For example the following render callback would result in a runtime error or at least an unexpected result for the user: {{{ badRender w h = drawSquare }}} To allow the type checker to enforce correct usage, we can use different monads which just wrap the IO monad as follows: {{{ newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO) newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO) type RenderCallback = Int -> Int -> RenderM () clear :: RenderM () scene :: DrawM () -> RenderM () drawSquare :: DrawM () }}} Now the good render function is well typed and the badRender function is ill typed. With the current GHC implementation, it is possible to provide the interface above by using some fiddly wrapper functions to remove the wrapper monads and replace them with the IO monad, for example: {{{ type RenderCallbackIO = Int -> Int -> IO () foreign import ccall "wrapper" mkRenderCallbackIO :: RenderCallbackIO -> IO (FunPtr RenderCallbackIO) dropRenderM :: RenderCallback -> RenderCallbackIO dropRenderM f x y = let RenderM io = f x y in io foreign import ccall api_onRender :: FunPtr RenderCallbackIO -> IO () onRender :: RenderCallback -> IO () onRender f = mkRenderCallbackIO (dropRenderM f) >>= api_onRender foreign import ccall api_clear :: IO () clear :: RenderM () clear = liftIO $ api_clear }}} As far as I can tell, GHC currently optimizes out all the overhead involved in converting between RenderM and IO. However the extra marshalling functions are fiddly to write, in particular since different versions of dropRenderM would be needed for different numbers of arguments in whatever function returns something in RenderM, and all these extra functions also obscure the simplicity of the original design. Therefore I propose that for any monad M defined by: {{{ newtype M a = M (IO a) deriving (Functor, Monad, MonadIO) }}} M a should be able to appear in place of IO a anywhere in a foreign function definition since all 'M' does is to enforce typing on the Haskell side and has no relevance to the foreign language API, just as IO has no relevance to the foreign language either. This would mean we'd no longer have to write extra wrapper functions and rely on the compiler optimizing them out. A related point is that the "API-safety == type correctness" gained by using different monads can at the moment be subverted because the entry point into a Haskell program is the main function which returns a value of type IO (). This means that initialization code for any API must be able to run in the IO monad. However every monad discussed above allows you to lift IO operations into it, so there is nothing to stop someone trying to make a nested re-initialization of the API in the middle of a callback... It is necessary to allow IO actions to be lifted into the callback monads so the callbacks can make use of IORefs etc. However it is undesirable to allow the API to be re-initialized (in such a nested way). Therefore I propose (perhaps this should have been a separate ticket but I don't know how to link two tickets together so I've bundled both issues in this ticket) that there should be an alternative entry point into a Haskell program with the following type: {{{ newtype MainM a = MainM (IO a) deriving (Functor, Monad, MonadIO) _main :: MainM () }}} with this default implementation: {{{ _main = liftIO $ main }}} so that all existing programs will still work. If _main is explicitly defined by the user, the user's definition should be used instead, and any definition of "main" will have no special significance. This would allow the API's initialization function to be safely typed as: {{{ runGraphicsWindow :: IO () -> MainM () _main = runGraphicsWindow $ do onRender render }}} Thus the user would be prevented from making nested calls to the initialization function.

1 0