News aggregator
John's Combinatory Logic Playground
Haskell Platform 2012.4.0.0
Either example
Haskell Weekly News: Issue 257
haskell - A monad is just a monoid in the category of endofunctors, what's the problem? - Stack Overflow
What is FRP?
A list of Haskell-related quotes?
ANN: config-select : How to use ghc-vis when your libraries are all compiled with profiling...
GHCi (7.4.2) is working on ARM
User defined literals for Haskell?
I work on a C++ compiler at my day job, but I use Haskell wherever possible. One of the features we're working on is user-defined literals for C++11, and it got me thinking about whether this sort of syntax extension would be useful for Haskell, too. Are there any proposals in progress? Any reason to abandon hope of seeing this?
The feature essentially allows you to define extra syntax on literals. The user defines the syntax by providing a function that maps the characters of the syntax to the desired output type. For example: 10cm is passed to a function cm :: String -> Length, and the resulting literal is of type Length.
Granted a feature like this would be much less useful in Haskell, since polymorphism is more effective and explicit function application is usually good enough where polymorphism isn't, but there might still be useful cases. And of course it leads to prettier and easier-to-read code. Thoughts?
submitted by pherlo[link] [14 comments]
parellella has a forum board for haskell. anyone working in this direction?
How far compilers are allowed to go withoptimizations?
Yesod Web Framework: Authentication during Testing
This is cookbook recipe, also available from the Wiki.
When testing a real application using Yesod.Test, each test case may need to perform a login. This is not difficult, but as it involves several steps, it is a little tedious to work through the details.
Here is some example code. It is designed around the user/password authentication provided by Yesod.Auth.HashDB, but can probably be used as a model for other authentication schemes.
The idea is to be able write test specs which go like this:
homeSpecs :: Specs homeSpecs = describe "The home page" $ do it "requires login" $ do needsLogin GET "/" it "looks right" $ do doLogin "testuser" "testpassword" get_ "/" statusIs 200 bodyContains "Welcome"A few things may need changing for your particular usage:
- The testRoot, which is probably the same as the approot for the Testing environment in your settings.yml file
- The "Login" string used to confirm we have reached the login page.
So with those caveats, here we are. Use it as you wish!
{-# LANGUAGE OverloadedStrings #-} module TestTools ( assertFailure, urlPath, needsLogin, doLogin, StdMethod(..), ) where import TestImport import qualified Data.ByteString as B import Data.Text (Text, unpack, pack) import Data.Text.Encoding (encodeUtf8, decodeUtf8) import Network.URI (URI(uriPath), parseURI) import Network.HTTP.Types (StdMethod(..), renderStdMethod) -- Adjust as necessary to the url prefix in the Testing configuration testRoot :: B.ByteString testRoot = "https://test.host/" -- Force failure by swearing that black is white, and pigs can fly... assertFailure :: String -> OneSpec conn () assertFailure msg = assertEqual msg True False -- Convert an absolute URL (eg extracted from responses) to just the path -- for use in test requests. urlPath :: Text -> Text urlPath = pack . maybe "" uriPath . parseURI . unpack -- Internal use only - actual urls are ascii, so exact encoding is -- irrelevant urlPathB :: B.ByteString -> B.ByteString urlPathB = encodeUtf8 . urlPath . decodeUtf8 -- Stages in login process, used below firstRedirect :: StdMethod -> B.ByteString -> OneSpec conn (Maybe B.ByteString) firstRedirect method url = do doRequest (renderStdMethod method) url $ return () extractLocation -- We should get redirected to the login page assertLoginPage :: B.ByteString -> OneSpec conn () assertLoginPage loc = do assertEqual "correct login redirection location" (testRoot `B.append` "/auth/login") loc get_ $ urlPathB loc statusIs 200 bodyContains "Login" submitLogin :: Text -> Text -> OneSpec conn (Maybe B.ByteString) submitLogin user pass = do -- Ideally we would extract this url from the login form on the -- current page post (urlPathB testRoot `B.append` "/auth/page/hashdb/login") $ do byName "username" user byName "password" pass extractLocation -- Successful login should redirect to the home page extractLocation :: OneSpec conn (Maybe B.ByteString) extractLocation = do statusIs 303 withResponse ( \ SResponse { simpleHeaders = h } -> return $ lookup "Location" h ) -- Check that accessing the url with the given method requires login, and -- that it redirects us to what looks like the login page. -- needsLogin :: StdMethod -> B.ByteString -> OneSpec conn () needsLogin method url = do mbloc <- firstRedirect method url maybe (assertFailure "Should have location header") assertLoginPage mbloc -- Do a login (using hashdb auth). This just attempts to go to the home -- url, and follows through the login process. It should probably be the -- first thing in each "it" spec. -- doLogin :: Text -> Text -> OneSpec conn () doLogin user pass = do mbloc <- firstRedirect GET $ urlPathB testRoot maybe (assertFailure "Should have location header") assertLoginPage mbloc mbloc2 <- submitLogin user pass maybe (assertFailure "Should have second location header") (assertEqual "Check after-login redirection" testRoot) mbloc2Jan Stolarek: To Mock a Mockingbird or: How I learned to stop worrying and learned combinatory logic
Yesterday I finished reading one of the most remarkable books I read in my life: “To Mock a Mockingbird and Other Logic Puzzles: Including an Amazing Adventure in Combinatory Logic” by Raymond Smullyan. When I finished reading The Little Schemer that book was listed as one of the suggested further readings. The title was quite intriguing so I got the book and started reading it. That was a year ago and I finished the book yesterday. Why? Because I got stuck and couldn’t understand some of the material. Luckily I now had some time to approach the book once again and grok it.
As the title suggests the book is a collection of logic puzzles. Out of six parts of the book – 25 chapters total – two are devoted to general logic puzzles, many of them about different aspects of truth telling. These can be regarded as a warm-up because in the third part the book makes a sudden turn towards combinatory logic. And this is the moment I found difficult in the book. Of course Smullyan doesn’t expect that readers work with combinators so he camouflages them as singing birds. Having some mathematical background I rejected this cover and tried to approach problems formally. Now, after reading the book, I think this was a major mistake that lead to my failure. I wasn’t able to deal with first 10 puzzles but I was more or less able to follow the solutions. Still I felt that reading solutions without being able to solve puzzles by myself was cheating so I gave up. A few months later I made another approach to the book but the results were exactly the same. Three weeks ago I made a third attempt, but I decided not to give up even if I won’t be able to come up with my own solutions. I figured that being able to only understand given solutions is completely fine. That decision turned out to be a good one. Although at first I wasn’t able to solve puzzles on my own at some point things just clicked. I solved one puzzle, then another and another and I realized that I know how to solve most of the puzzles. From now on the book went quite smoothly. Part four about logical paradoxes and inconsistencies in logical systems gave me some problems and I was afraid that each subsequent part will be equally challenging but it turned out that it was not the case. Part five gives a nice overview of computations using SKI combinators, while part six presents Church encoding of natural numbers and culminates with a proof of Gödel’s theorem.
Some adviceThe book is challenging on the one hand but it is also very rewarding. One of the most satisfying moments was realizing that I am able to write expressions like
and then seeing that these are in fact nothing more but recursive programs. However it took me some work to get to this point and I think I can give future readers some advice about approaching the book. I’ve seen people on the internet saying they don’t understand parts of the book about combinators. In fact this is the same problem I faced on my initial contact. So my advice number one is: don’t give up. It looks like working with combinators just isn’t an inborn talent for most of us. It’s something that we just need to learn and it’s completely fine if you can’t figure out solutions on your own. It is important however to follow solutions given in the book. At some point you should understand how all of this works. Also don’t make my mistake of trying too formalize things to much. Don’t try to apply presented facts about combinators to anything else you know like maths or functional programming. This seems to only bring confusion. At some point things will become clear, but until then be patient. I wasn’t and in my attempts I even tried to introduce universal and existential quantification, which was a complete overkill. Also, it is very important to make notes. Keep conclusions of the puzzles in a notebook so you have easy access to a list of known facts. This is crucial since some solutions are based on facts proved 100 pages earlier. I also suggest having a separate scratch-pad.
SummaryTo “Mock a Mockingbrd” was a very insightful book and one of the most unusual ones I have read. It presents difficult material in a fun and entertaining way, but don’t be fooled – you will spend hours with pen and paper to complete this book. I highly recommend it to anyone interested in logic and functional programming. What functional programming has to do with it? Unrelated as it may seem I feel that this book has given me knowledge necessary to tackle type-level programming in Haskell. Just three weeks ago this seemed like a complete black magic and now it looks comprehensible.