Skip to main content

Home/ Haskell/ Group items tagged string

Rss Feed Group items tagged

Javier Neira

Haskell: The Confusing Parts - 0 views

  • f $ x = f x(f . g) x = f (g x)-- Some quick examples of using these. The following line...putStrLn (take 12 (map foo (bar ++ "ack")))-- ...can be rewritten as...putStrLn $ take 12 $ map foo $ bar ++ "ack"(putStrLn . take 12 . map foo) (bar ++ "ack")putStrLn . take 12 . map foo $ bar ++ "ack" In terms of good Haskell style, the last example above is preferable to the others. By the way, note that ($) has the lowest precedence (zero) of any operator, so you can almost always use arbitrary syntax on either side of it.
  • -- Actual definitions:f $ x = f x(f . g) x = f (g x)-- Some quick examples of using these. The following line...putStrLn (take 12 (map foo (bar ++ "ack")))-- ...can be rewritten as...putStrLn $ take 12 $ map foo $ bar ++ "ack"(putStrLn . take 12 . map foo) (bar ++ "ack")putStrLn . take 12 . map foo $ bar ++ "ack"
  • putStrLn (take 12 (map foo (bar ++ "ack")))-- ...can be rewritten as...putStrLn $ take 12 $ map foo $ bar ++ "ack"(putStrLn . take 12 . map foo) (bar ++ "ack")putStrLn . take 12 . map foo $ bar ++ "ack"
  • ...7 more annotations...
  • putStrLn (take 12 (map foo (bar ++ "ack")))
  • anywhere you might write \x -> foo x [1..10], you should instead write flip foo [1..10], where flip is a standard Prelude function that flips the first two arguments of whatever function you give it
  • two arguments of whatever
  • anywhere you might write \x -> foo x [1..10], you should instead write flip foo [1..10], where flip is a standard Prelude function that flips the first
  • The curry and uncurry functions stand in for \f x y -> f (x, y) and \f (x, y) -> f x y, respectively.
  • The curry and uncurry functions stand in for \f x y -> f (x, y)
  • I will point out that return is, in fact, not a return statement. It’s a function, and an inappropriately named function, at that. Writing return () in your do block will not cause the function to return.
  •  
    If you're used to the C family of languages, or the closely related family of "scripting languages," Haskell's syntax (mainly) is a bit baffling at first. For some people, it can even seem like it's sneaking out from under you every time you think you understand it. This is sort of a FAQ for people who are new to Haskell, or scared away by its syntax.
Javier Neira

jaspervdj - Maybe, null, and boilerplate code - 0 views

  • A first goal they serve is as "unassigned variables". I will not cover that here, instead I will focus on another use: abnormal return values.
  • So, null is some sort of "Not found" error here. But wait - they could have used an Exception here!
  • We see a similar behavior here: when the object is found, we get a Just a, and when it is not found, we get Nothing - comparable to a null pointer.
  • ...5 more annotations...
  • So, while we can get a null back from a function, we should never give it to a function.
  • Now, if you have written a lot of Java code, you know that checking for null is a vital part of the job, and fragments like the one above are pretty common.
  • In Haskell, however, Maybe is also a monad - and monads can be used to prevent common patterns in code - in other words, they assist you in the D.R.Y.-principle2. We can therefore write the above snippet again using do-notation3.
  • getPathMonth :: Map String String -> Maybe MonthgetPathMonth m = do p <- lookup "path" m d <- parseDate p return $ getMonth d
  • he whole "check-for-null-and-short-circuit" behavior is defined by the Maybe monad -
  •  
    getPathMonth :: Map String String -> Maybe Month getPathMonth m = case M.lookup "path" m of Nothing -> Nothing (Just p) -> case parseDate p of Nothing -> Nothing (Just d) -> Just (getMonth d) getPathMonth :: Map String String -> Maybe Month getPathMonth m = do p <- parseDate p return $ getMonth d
Javier Neira

Fatvat: Web Sockets and Haskell - 0 views

  •  
    import Network import System.IO import Control.Concurrent import Char serverHandshake = "HTTP/1.1 101 Web Socket Protocol Handshake\r\n\ \Upgrade: WebSocket\r\n\ \Connection: Upgrade\r\n\ \WebSocket-Origin: http://localhost\r\n\ \WebSocket-Location: ws://localhost:9876/\r\n\ \WebSocket-Protocol: sample\r\n\r\n\0" acceptLoop socket = forever $ do (h,_,_) IO () listenLoop h = do sendFrame h "hello from haskell" threadDelay (3 * 1000000) sendFrame h "it works!" return () sendFrame :: Handle -> String -> IO () sendFrame h s = do hPutChar h (chr 0) hPutStr h s hPutChar h (chr 255)
Javier Neira

Existential type - HaskellWiki - 0 views

  • First of all, it is now impossible for a function to demand a Worker having a specific type of buffer. Second, the type of foo can now be derived automatically without needing an explicit type signature. (No monomorphism restriction.) Thirdly, since code now has no idea what type the buffer function returns, you are more limited in what you can do to it.
  • This illustrates creating a heterogeneous list, all of whose members implement "Show", and progressing through that list to show these items: data Obj = forall a. (Show a) =&gt; Obj a &nbsp; xs :: [Obj] xs = [Obj 1, Obj "foo", Obj 'c'] &nbsp; doShow :: [Obj] -&gt; String doShow [] = "" doShow ((Obj x):xs) = show x ++ doShow xs With output: doShow xs ==&gt; "1\"foo\"'c'"
  • Existential types in conjunction with type classes can be used to emulate the dynamic dispatch mechanism of object oriented programming languages. To illustrate this concept I show how a classic example from object oriented programming can be encoded in Haskell.
1 - 7 of 7
Showing 20 items per page