Blog Archive

Monday, December 27, 2010

Editing XML in Haskell

edit: Here's an hpaste for the solution I eventually came up with: http://hpaste.org/42628/xml_cursor_monad

I recently found myself wanting to make small tweaks to an XML file not under my control before processing it in my Haskell app.

My end goal would be a way to a) declare what in the XML I want to edit and then b) apply a function to the located element and have it update in place.

The hxt (Haskell Xml Toolkit) has a lot of pieces, and includes and XPath parser, so I looked at it first. But like XSLT, hxt seems geared towards XML processing - not editing. It has tools for applying an translation recursively through a tree, but that requires finding an element based on a predicate on the element, not based on it's location within the document. hxt does let you extract elements based on location, but I don't see how to put the original document back together again. Maybe I'm missing something.

Then I noticed that the xml package (sometimes referred to as xml-light) has a Cursor written for it! So all I need to do is navigate the cursor down to where I need it, apply the update function and then I'm done. That's declarative enough for me.

There were two problems with this:
  1. A lot of the cursor manipulation functions return maybe types
  2. I didn't feel comfortable composing functions on cursors - if a sub-function goes off the deep end it could have left the cursor anywhere in the document DOM

So I did what any other Haskell programmer would do - I wrote my own XML editing monad to fix and then encapsulate the problems above.
> data Update a = ...

The Update type has instances for Monad, Functor, and Applicative - and to handle the failing traversal functions it has instances for Alternative and MonadPlus.

It has the primitive operations:

> runUpdate :: Cursor -> Update a -> Maybe (a, Cursor)

> perform :: (Cursor -> Maybe Cursor) -> Update ()

> asks :: (Cursor -> a) -> Update a

These are used to wrap up all of the functions from Text.XML.Light.Cursor in a straightforward way.

To give me more control over the composition of cursor update there are also the following primitives:

> sandbox :: Update a -> Update a

> run :: Update a -> Update ()

The function 'sandbox' executes the passed in action, but contains it to the current scope of the cursor - the action may not access the parent or siblings of the current node. In addition, the cursor is returned to its current position regardless of where the passed in action left it.

The function 'run' is the same as 'sandbox' - except that if the passed action fails we pretend that nothing happened.

So go nuts - you can now declare edits and traversals without worrying about how to fit them in to the bigger picture. We have combinators for that.

Am I off the deep end with this? Are there other tools on Hackage I should be using?

Monday, December 28, 2009

Adventures in Parsec

Part I - An introduction to Parsec

The basic type of a monadic parser is a function from an input string to a parse result, along with the rest of the string to be parsed.

One example is ReadS a = String -> [(a,String)], where returning a null list indicates no parse, and returning multiple values allows a parser to indicate ambiguity.

There are a few deficiencies in this data structure:
  • The representation of ambiguity can lead to large space leaks, as the traditional combinators allow for unlimited backtracking
  • It is difficult to wedge good error reporting into this setup.

The parsec parser, instead of returning a list of parses returns one of four results of the parse:

  • I errored and did not consume input
  • I errored and did consume input
  • I succeded and did not consume input
  • I succeded and did consume input

The idea is that once a parser consumes any input (that is, looks ahead more than one charecter) we prohibit backtracking. This limitation on backtracking means that we can drop the beging of the token-stream sooner, allowing it to be cleaned up by the garbage collector. There are also advantages to error reporting to making these distinctions.

Partridge & Wright seem to be the first to have introduced this splitting of the return value of a parse, but I can't find a non-paywalled version of their paper "Predictive parser combinators need four values to report errors." It seems like exactly the sort of paper I should be reading, but I'm also not sure on how to get in touch with the authors. Edit: Thanks to Chung-chieh Shan for sending me a copy of Partridge & Wright.

We still have a problem - we still need to hang on to the input string until we know that the parser succeeded or failed. In many cases we know that the parser consumes input long before we know that it was successful.

Parsec combines two data structures to return these four values:

data Consumed a = Consumed a | Empty a

data Reply a = Ok a State Message | Error Message

type Parser a = State -> Cosumed (Reply a)

Now our choice combinator can determine if a parser consumes input before we finish the parse - this means that we allow the GC to drop the head of the input as soon as the parser consumes any of it, solving the mentioned memory leak.

Part II - My obsession with functionalizing monad transformers

I have a bit of an obsession with the dual nature of data and functions, and converting algebraic data structures to their equivalent function form to see what I can uncover.

For example, in the mtl the ErrorT monad transformer is defined as follows:

newtype ErrorT e m a = ErrorT {
runErrorT :: m (Either e a)
}

throwError :: e -> ErrorT e m a
throwError = ErrorT . return . Left

When we give this monad semantics, in between each (>>=) we check the value on the LHS, ad if it's in Left we short circuit what's on the RHS so that the error value returns all the way to the end of the computation. This means at each stage of the computation we have to do a case analysis of the inner Eitehr value. Since the inner type is 'm (Either e a)' we also need to perform a (>>=) operation in the inner monad to perform (>>=) in ErrorT.

An equivalent type is:

newtype ErrorT e m a = ErrorT {
unError :: forall r . (e -> m r) -- error!
-> (a -> m r) -- success!
-> m r
}


The second function is our success continuation - it's passed in to an action, and called if the action successfully returns a value -

return :: a -> ErrorT e m a
return x = ErrorT $ \_ successK ->
successK x

The first function is the error continuation, and is called if an action needs to terminate abnormally:

throwError :: e -> ErrorT e m a
throwError e = ErrorT $ \errorK _ ->
errorK e

We then weave the continuations together in the implementation of (>>=) to get the
short-curcuiting we want:

(>>=) :: ErrorT e m a -> (a -> ErrorT e m b) -> ErrorT e m b
m >>= f = ErrorT $ \topErrorK topSuccessK->
unError m topErrorK $ \x ->
unError (f x) topErrorK topSuccessK

The LHS is given our top-level erorr handler to call if it errors out. If it succeds, it calls a lambda which evaluates the RHS. The RHS is given the same error handler as the LHS, and the success continuation for the RHS is the success continuation for the expression as a whole. So successes move from left to right, but if there's an error it can only go to one place.

Interesting points to note:
  • There's no case analysis on data structures - short circuiting works because every action gets passed the same error continuation (unless we implement a 'catch' combinator).
  • There are no constraints on the nature of the 'm' type variable. ErrorT is a monad independent of whatever it's wrapping.

I haven't benchmarked whether or not this is faster for anything, but I find the whole thing a lot of fun.

Part III - A faster Parsec 3

Parsec version 3 was released on hackage a bit back, and it improved on the prior version in two ways:

1) It was a monad transformer. This is pretty fun - as an exercise I wrote a unification engine in a monad, and then wrapped parsec around it. When it hit a syntax error in equality terms it could print the in-progress results of performing unification up until that point. Very fun.

2) It was parameterized over the input type. The previous version required a list of tokens as input.

The downside is that (when using the non-transformer compatibility layer) parsec-3 is 1.8x slower in some benchmarks as parsec-2.

But how can it be made faster without losing the new abstractions? The first thing I tried was to have parsec be split into two parsers - one transformer and one not, with two implementations of the core combinators. The core combinators would be moved into a type-class, and the higher-level combinators would then be polymorphic over either of them. Foks writing parsers could write them polymorphic, and then the folks running the parsers only pay for the new abstractions if they need it.

It worked, but the type-class itself didn't make any sense - it was more of a "put what I need over in this bucket" job than a careful consideration of what the core primitives of a monadic parser like parsec truly are. I also seem to remember that in introduced a problem in the compatibility layer, but it's been a while since I did that testing. You can see the haddocks here:

Text.Parsec.Class
Text.Parsec.Core
Text.Parsec.Combinator

This is also a radical restructuring of the parsec API - new constraints and new modules, and changing the meaning of another. Lots of fun.

Another approach which is a much smaller change to the visible part of parsec but is a much more radical change to the inner workings is to do to ParsecT what we did to ErrorT - return via continuations rather than an algebraic data type. Where ErrorT needed two continuations, ParsecT requires four:

newtype ParsecT s u m a
= ParsecT {unParser :: forall b .
State s u
-> (a -> State s u -> ParseError -> m b) -- consumed ok
-> (ParseError -> m b) -- consumed error
-> (a -> State s u -> ParseError -> m b) -- empty ok
-> (ParseError -> m b) -- empty error
-> m b
}

When the parser errors we call one of the error continuations with the information about the error. When the parse succeeds we call one of the success continuations, passing along the parsed value and the new state of the parse.

And this is practically as fast as parsec-2 for folks not using the new abstractions in parsec-3. I believe it's because we no longer pay for the abstraction in the core cobinators - none of the primitives or combinators place any constraints on the type of 'm', just as for the continuation-based ErrorT transformer.

But what of Patridge & Wright's space leak? Where is the laziness introduced in the Parsec technical report? I've gone from the nested structure back to a flat structure. How can this be as fast as the Parsec of the report if I've re-introduced the space leak?

It was the case analisys on the not-lazy-enough return value of the parser which introduced the space leak, but we don't have have that. We just pass continuations in to the parsers, which may call them as they will. As long as the core primitves aren't capable of calling the "I haven't consummed input" continuations after they have consumed input then we're free to garbage collect those continuations as well as the consummed bits of input. Space leak averted.

The darcs repo for the continuation based parsec is here: http://community.haskell.org/~aslatter/code/parsec/cps/

Appendix A: Further adventures in ErrorT

In case you needed convincing that the above formulation of ErrorT is equivalent to that in the mtl:

catch :: ErrorT e m a -> (e -> ErrorT e m a) ->ErrorT e m a
catch m handler = ErrorT $ \topErrorK topSuccessK ->
let errorK e = unError (handler e) topErrorK topSuccessK
in unError m errorK topSuccessK

runErrorT :: Monad m => ErrorT e m a -> m (Either e a)
runErrorT (ErrorT f) = f errorK successK
where successK = return . Right
errorK = return . Left

Saturday, April 18, 2009

Using Haskeline

Earlier today I decided to unearth an old project of mine - figuring that the best way to learn two languages was to implement one in the other, I wrote a MUMPS interpreter in Haskell. I was learning MUMPS for work, and Haskell for fun.

Back when I wrote it, I used readline in the REPL part of the interpreter - during the cleanup I wanted to move away from readline as GHC doesn't ship with it any more, and sometimes it can be a pain to install on its own. So I switched to Haskeline. It doesn't ship with GHC either, but it's proven easier for me to install.

Haskeline has got a really friendly API, with all of the functions operating inside the InputT m monad transformer. "Great," I think, "I can just pile this on top of my existing monad transformers stack in the interpreter!"

All was not so simple, as InputT has it's own instance of MonadState and MonadReader which allows the user of the library to peer into the guts of the implementation. But I didn't want to monkey with my text entry, I just wanted it to work and get out of my way, and I wanted the rest of my code to use the MonadState instance further down the stack that I had already set up.

So I wrote a small wrapper for Haskeline that's more friendly to mtl-style monad transformer composition. As written, it only composes with MonadIO and MonadState, but it would be straightforward to do more.

My wrapper uses HaskelineT instead of InputT, and exposes the same core functions as Haskeline (except for withInterrupt). It doesn't do anything I couldn't do by peppering lifts all over the place, but this way feels a but cleaner to me - Haskeline keeps its workings to itself, and I don't have to think about the order of the layered monad transformers.


{-# LANGUAGE FlexibleInstances
, MultiParamTypeClasses
, UndecidableInstances
, GeneralizedNewtypeDeriving
#-}

import qualified System.Console.Haskeline as H
import System.Console.Haskeline.Completion
import System.Console.Haskeline.MonadException

import Control.Applicative
import Control.Monad.State

newtype HaskelineT m a = HaskelineT {unHaskeline :: H.InputT m a}
deriving (Monad, Functor, Applicative, MonadIO, MonadException, MonadTrans, MonadHaskeline)

runHaskelineT :: MonadException m => H.Settings m -> HaskelineT m a -> m a
runHaskelineT s m = H.runInputT s (unHaskeline m)

runHaskelineTWithPrefs :: MonadException m => H.Prefs -> H.Settings m -> HaskelineT m a -> m a
runHaskelineTWithPrefs p s m = H.runInputTWithPrefs p s (unHaskeline m)

class MonadException m => MonadHaskeline m where
getInputLine :: String -> m (Maybe String)
getInputChar :: String -> m (Maybe Char)
outputStr :: String -> m ()
outputStrLn :: String -> m ()


instance MonadException m => MonadHaskeline (H.InputT m) where
getInputLine = H.getInputLine
getInputChar = H.getInputChar
outputStr = H.outputStr
outputStrLn = H.outputStrLn


instance MonadState s m => MonadState s (HaskelineT m) where
get = lift get
put = lift . put

instance MonadHaskeline m => MonadHaskeline (StateT s m) where
getInputLine = lift . getInputLine
getInputChar = lift . getInputChar
outputStr = lift . outputStr
outputStrLn = lift . outputStrLn

Sunday, February 15, 2009

MaybeT - The CPS Version

> {-# LANGUAGE Rank2Types #-}
> import Control.Monad
I think I finally understand writing code into continuation passing style. I've understood it at an academic level for some time - but that's different from being able to write the code.

This post presents a different implementation of the Maybe monad transformer - usually presented as so:

data MaybeT m a = MaybeT {runMaybeT :: m (Maybe a)}
which can be used to add the notion of short-circuiting failure to any other monad (sortof a simpler version of ErrorT from the MTL).
I first came across MaybeT in a page on the Haskell Wiki.
This presentation of MaybeT uses the Church encoding of the data-type:
> newtype MaybeT m a = MaybeT {unMaybeT :: forall b . m b -> (a -> m b) -> m b}
Note the similarity to the Prelude function maybe. We can unwrap the transformer like so:

> runMaybeT :: Monad m => MaybeT m a -> m (Maybe a)
> runMaybeT m = unMaybeT m (return Nothing) (return . Just)
This runMaybeT should be a drop-in replacement for the old one.
The advantage here is that we can write the Monad and MonadPlus instances without calling bind or return in the underlying monad m, and without doing any case analysis on Just or Nothing values:
> instance Monad (MaybeT m) where
> return x = MaybeT $ \_ suc -> suc a
>
> m >>= k = MaybeT $ \fail suc ->
> unMaybeT m fail $ \x ->
> unMaybeT (k x) fail suc
>
> fail _ = mzero

> instance MonadPlus (MaybeT m) where
> mzero = MaybeT $ \fail _ -> fail
>
> m `mplus` n = MaybeT $ \fail suc ->
> unMaybeT m (unMaybeT n fail suc) suc
It's just a matter of threading the failure and success continuations to the right place at the right time.
To show that this is equivalent to the old implementation, here's a re-write of the old MaybeT data constructor from above:

> fromMaybe :: Monad m => m (Maybe a) -> MaybeT m a
> fromMaybe m = MaybeT $ \fail suc -> do
> res <- m
> case res of
> Nothing -> fail
> Just x -> suc x

So anything you can do with the other version, you can do with this version. And for most things it should be a drop-in replacement.

Thursday, February 12, 2009

Dependencies in Hackage, revisited

In a previous post I described how to scrape the Hackage website to do reverse lookups on package dependency data for packages hosted on Hackage.

With the release of the new HTTP library (version 4000) that code doesn't work anymore. This post presents a different solution to the problem.

Instead of pulling data out of html documents, we instead load and parse the local .tar file that cabal-install uses to do its own dependency chasing.

You'll need tar and utf8-string from Hackage.

First, the necessary imports:

> import Data.Maybe
> import Data.List

> import Codec.Archive.Tar

> import Data.ByteString.Lazy (ByteString)
> import qualified Data.ByteString.Lazy as BS

> import qualified Data.ByteString.Lazy.UTF8 as UTF8

> import System.IO
> import System.Environment

> import Distribution.Text
> import Distribution.Package
> import Distribution.PackageDescription
> import Distribution.PackageDescription.Parse
And now the 'main' method.

The first argument is the name of the package you're checking dependencies for, and the second argument is the path to the Hackage index tar-file (for me this is ~/.cabal/packages/hackage.haskell.org/00-index.tar).

> main :: IO ()
> main = do
> [target,tarball] <- getArgs
> withFile tarball ReadMode $ \h -> do
> contents <- BS.hGetContents h
> let matches = matchesFromIndex contents (== target)
> sequence_ $ map (print . disp) matches

And then we have the function which, given the contents of the tar-file as a ByteString, returns back the list of PackageIds which depend on the indicated package.

> matchesFromIndex :: ByteString -> (String -> Bool) -> [PackageId]
> matchesFromIndex index p =

> let tarchive = readTarArchive index
> cabalFiles = map UTF8.toString $ findCabalEntries tarchive
> parseResults = map parsePackageDescription cabalFiles
> gPckgDiscs = okayOnly parseResults
> matches = filter (match p) gPckgDiscs

> in map packageId matches

> okayOnly :: [ParseResult a] -> [a]
> okayOnly = mapMaybe fromOkay
> where fromOkay (ParseOk _ a) = Just a
> fromOkay _ = Nothing

> -- Does this package have a dependency which matches our
> -- query?
> match :: (String -> Bool) -> GenericPackageDescription -> Bool
> match p pkg = any (matchDep p) (gPckgDeps pkg)

> -- Does this dependency match our query?
> matchDep :: (String -> Bool) -> Dependency -> Bool
> matchDep p (Dependency (PackageName name) _) = p name
There's a bit of black-magic going on here - I don't entirely understand the structure of the new 'library' and 'executable' sections of the .cabal file, but I scrape everything out which has the right type.

> gPckgDeps :: GenericPackageDescription -> [Dependency]
> gPckgDeps pkg = normalDeps ++ libDeps ++ execDeps
> where
> normalDeps = buildDepends $ packageDescription pkg

> libDeps = case condLibrary pkg of
> Nothing -> []
> Just cndTree -> depsFromCndTree exLibDeps cndTree

> execDeps = concatMap (depsFromCndTree exExecDeps . snd)
> (condExecutables pkg)

> exLibDeps = pkgconfigDepends . libBuildInfo
> exExecDeps = pkgconfigDepends . buildInfo

> depsFromCndTree f tree =
> let x = condTreeData tree

> parts = condTreeComponents tree
> mdlTrees = map mdl parts
> thrdTrees = mapMaybe thrd parts

> trees = mdlTrees ++ thrdTrees


> in f x ++
> condTreeConstraints tree ++
> concatMap (depsFromCndTree f) trees

> where mdl (_,x,_) = x
> thrd (_,_,x) = x

And this is the bit which takes the decoded tar-file and returns back the entries which look like they could be .cabal files.

> findCabalEntries :: TarArchive -> [ByteString]
> findCabalEntries TarArchive{archiveEntries = xs} = mapMaybe go xs

> where go :: TarEntry -> Maybe ByteString
> go x | fileType x /= TarNormalFile = Nothing
> | isBoringName (fileName x) = Nothing
> | otherwise = Just $ entryData x

> fileType = tarFileType . entryHeader
> fileName = tarFileName . entryHeader

> isBoringName = not . isSuffixOf ".cabal"


Not too shabby.

Saturday, June 21, 2008

Haskell Snippets

I'm a huge fan of the function mapMaybe, but once I move from the 'Maybe' monad into something more complex (such as ReaderT r Maybe) things become tricky.

First, what is mapMaybe?

Its type is: (a -> Maybe b) -> [a] -> [b]

It maps the input function over the list, and drops any values which evaluate to nothing. It's like a combination of map and filter, where the input function is given the option to either transform the input or filter it out.

But then I needed more information threaded around in my functions, and the types went from a -> Maybe b to a -> ReaderT r Maybe b.

So I needed:

> mapAlt :: Alternative f => (a -> f b) -> [a] -> f [b]


It's just like mapMaybe, except it works for any Alternative functor.

The output is still in the functor f so I can have it work for effectful monads and such, but it will always return a value (even if it's the empty list).

Here's the implementation:

> mapAlt f xs = go xs
> where go [] = pure []
> go (y:ys) = (pure (:) <*> f y <*> go ys)
> <|> go ys
Links:
Hurrah for simple, useful functions.

Sunday, February 10, 2008

HTML Scraping with TagSoup

Earlier today I wanted to know the packages on Hackage which stated a dependency on Parsec, so I wrote a command-line utility to do it. This post presents the utility.

The plan is simple: grab http://hackage.haskell.org/packages/archive/pkg-list.html, extract all of the links which look like links to packages, and then for each of the package-description pages find out if the dependency list includes parsec. If it does, print the package name.

First, a few preliminaries:

> import Data.Maybe
> import Network.HTTP
> import Network.URI
> import System.Environment
> import Text.HTML.TagSoup
> import Text.Regex.Base
> import Text.Regex.Posix.String
> import Text.Regex.Posix.Wrap

You could probably use a different Regex package if you wanted to without too much trouble.

First up, a few strings broken out of the body of the program for convenience should they need changing.

> name = "hackage-dep"
> version = "0.1.0"

> baseURIString = "http://hackage.haskell.org"
> packagesURI =
> fromJust $ parseURI $ baseURIString ++ "/packages/archive/pkg-list.html"
> basePath = "/cgi-bin/hackage-scripts/package/"
The function parseURI comes from the Network.URI module. It converts a String to the URI datatype used by the Network.* modules.

Next, I need a few functions to fetch an HTML document given a URI:

> mkSimpleGet :: URI -> Request
> mkSimpleGet uri =
> Request uri GET [Header HdrUserAgent (name ++ " v" ++ version)] []

> simpleGet :: URI -> IO (Result Response)
> simpleGet = simpleHTTP . mkSimpleGet

> body :: Result Response -> Either String String
> body (Right (Response (2,_,_) _ _ str)) = Right str
> body (Right (Response code _ _ _)) = Left $ printCode code
> body (Left e) = Left $ show e

> printCode :: ResponseCode -> String
> printCode (a,b,c) = show a ++ show b ++ show c

> errorString :: String -> String -> String
> errorString uri err =
> "Error getting " ++ uri ++ "\n" ++ "Error: " ++ err

The two interesting functions here are simpleGet and body: simpleGet performs an HTTP GET request with the passed-in URI, and body extracts the body from the response if it was successful.
Now we can start on the HTML manipulation.

> type HTML = String

> links :: HTML -> [Tag]
> links = filter (~== TagOpen "a" []) . parseTags
links converts an HTML document into a list of link tags, using TagSoup.

And then the function packageInfo extracts the package name from a link to that package.

> type Package = String

> packageInfo :: Tag -> Maybe Package
> packageInfo (TagOpen "a" []) = Nothing
> packageInfo t@(TagOpen "a" attrs) =
> case fromAttrib "href" t of
> [] -> Nothing
> path -> info path
> packageInfo _ = Nothing

> packageName = "^" ++ basePath ++ "(.+)$"

> info :: String -> Maybe Package
> info str =
> case str =~ packageName of
> (_,_,_,[]) -> Nothing
> (_,_,_,[package]) -> Just package
> (_::(String,String,String,[String])) -> Nothing
And once I have a list of package names, I'll want to grab the web-page describing the package:

> packageURI :: Package -> URI
> packageURI =
> fromJust . parseURI . ((baseURIString ++ basePath) ++)

> packageGet :: Package -> IO (Result Response)
> packageGet = simpleGet . packageURI
The idea is that I can call packageGet on an extracted Package, and then I can use the previously defined body function to get the HTML out of the HTTP response.

Now, let's get on with the main function:

> main :: IO ()
> main = do
> arg <- (do {[arg] <- getArgs; return arg})
> `catch`
> (\_ -> error "Requires a single command line argument")
> res <- simpleGet packagesURI
> case body res of
> Left str -> putStrLn $ errorString (show packagesURI) str
> Right html -> findDeps (=~ arg) $ filterJust $ map packageInfo $ links html

The filterJust $ map packageInfo $ links html bit extracts a list of package names from the HTML list pulled off of hackage. The function findDeps takes this list along with a passed in testing function and prints out which packages depend on the package specified at the command line. The passed-in testing function is just a regex-match based on the single command-line argument.

> filterJust :: [Maybe a] -> [a]
> filterJust xs = [x | Just x <- xs]

> findDeps :: (String -> Bool) -> [Package] -> IO ()
> findDeps p ps = mapM_ (printIfDep p) ps

> printIfDep :: (String -> Bool) -> Package -> IO ()
> printIfDep p pTest = do
> res <- packageGet pTest
> case body res of
> Left e -> putStrLn $ errorString pTest e
> Right html ->
> if hasDep html p
> then putStrLn pTest
> else return ()

The function hasDep picks the "Dependencies" field out of the passed-in HTML text, and then returns true if the passed-in test returns true on any bit of string in the dependencies field.

> hasDep :: HTML -> (String -> Bool) -> Bool
> hasDep html p =
> let tags = parseTags html
> depTags = takeWhile (~/= (TagClose "tr")) $
> drop 1 $
> dropWhile (~/= (TagText "Dependencies")) $
> tags
> depText = filterText depTags
>
> filterText xs = [x | TagText x <- xs] :: [String]
> in any p depText


After saving and compiling, executing ./Main parsec will (slowly) list all of the packages on Hackage which depend on Parsec. Success!

Exercise for the reader: Implement the above functionality by grabbing the 00-index.tar.gz off of Hackage instead of scraping HTML pages. This file contains all of the .cabal files for every version of every package hosted on Hackage. For bonus points cache the index on disk between calls.

Tuesday, February 05, 2008

Parsec as a monad transformer

The proposed Parsec3 package for Haskell has Parsec implemented as a monad transformer, which means I can do things like:

> data MyType
> = Foo
> | Baz
> | Err
> deriving Show

> parseMyType = (string "Foo" >> return Foo)
> <|> (string "Baz" >> return Baz)

> parseNoBaz = callCC $ \k -> do
> result <- parseMyType
> validateResult k result
> return result

> validateResult k Baz = k Err
> validateResult k _ = return ()

> manyNoBaz = parseNoBaz `sepBy` space

> test p s = flip runCont id (runPT p () "test" s)

Then, if I execute test manyNoBaz "Foo Foo Baz Foo" I get the result:

[Foo,Foo,Err,Foo]

This is a contrived example, but I think it's pretty neat.

Tuesday, January 01, 2008

Constraint synonyms in Haskell

Hello folks, and happy new year!

Earlier today I found myself writing the same sequence of long constraints on my type-signatures over and over again in a Haskell program I was working on. The program is still in flux, so that means the constraints may still change. As all of the functions call each-other, they need to have a similar set of constraints on their type signatures.

This means as the program evolves, I'll need to make a lot of similar changes all over the source file. I'm pretty lazy, so that doesn't sound like fun to me. At first I thought I could do something like this with regular type synonyms, but that requires all functions to share their entire type, not just a set of constraints.

There are a few ways I could've solved this problem:
  • Don't use type signatures
    I'm not using any fancy type-level hacks, so the compiler doesn't really need them. But I like having them to prove to myself that I really do know what my code does, and to provide better error messages.
  • CPP Macros
    I haven't tried this one - I just thought of it while writing this
  • Type Classes
    Which is what this post is about


Let's say I have a number of functions whose type signatures are along the lines of:
> myFunc :: (Eq b, Show b, MyClass b, MyOtherClass b) => Int -> String -> b -> b

and I don't like typing the (Eq b, Show b, MyClass b, MyOtherClass b) part over and over again. I can define a typeclass which captures all of those constraints:
> class (Eq b, Show b, MyClass b, MyOtherClass b) => MyConstraints b

along with a rule to populate the class:
> instance (Eq b, Show b, MyClass b, MyOtherClass b) => MyContraints b

I can now re-write the type-signature for myFunc as follows:
> myFunc :: MyConstraints b => Int -> String -> b -> b


This works for the following reasons:
  • Memebership in the class "MyConstraints" implies membership in all of the other classes, due to the constraint on the class defintion.
  • Every type which satisfies the constraints is a member of the "MyConstraints" class.


As another check, if you load the module defining myFunc into GHCi and ask for its type at the interactive prompt, it will report it as
myFunc :: (Eq b, Show b, MyClass b, MyOtherClass b) => Int -> String -> b -> b

Which is exactly what I wanted.

Saturday, December 01, 2007

Backwards State, or: The Power of Laziness

There's been a recent discussion of Automatic Differentiation in Haskell recently, which somehow found me reading Jerzy Karczmarczuk's paper "Lazy Time Reversal, and Automatic Differentiation," which then cited Philip Wadler's "The essence of functional programming" for the introduction of the backwards state monad, which I reproduce here because I think it's neat.

I'm going to assume that you're familiar with the Haskell state monad - in summary an action in the state monad is a function of the previous state, and produces a result paired with the next state.

The backwards state monad differs from this in that the flow of the state through the execution is revere to the flow of the results - that is, an action in the backwards state monad takes in the final value of the state and produces a result and the initial value.

This post is literate Haskell post - you should be able to copy and past it into a .lhs file and play with it in a Haskell interpreter. I use GHCi.

To that end, here's some of the up-front boilerplate so this all works:

> {-# LANGUAGE FlexibleInstances,
> MultiParamTypeClasses,
> RecursiveDo
> #-}
> import Data.List
> import Control.Monad.State

An Example


Here's the exercise: Given a tree of items, transform the tree to a tree of Ints such that each element is mapped to an Int, starting at 0. If an element occurs more than once in the tree, it must be mapped to the same Int each time.

The solution given in Control.Monad.State.Lazy does a walk of the tree, and carries around a list of all of the elements seen so far using the state monad. Each node is mapped to its position in this list. That is, the first node seen is mapped to 0, the second to 1, etc..

But what if I wanted to switch that up? What if wanted the last node seen in the walk mapped to 0, the second to last mapped to 1, and so on? How much would I need to change in the already existing solution given in Control.Monad.State.Lazy?

Not much! I'd just need to use the backwards state monad, where the state flows backwards through the thread of execution.

This is what the modified solution would look like:

> data Tree a = Nil | Node a (Tree a) (Tree a) deriving (Show, Eq)
> type Table a = [a]

> numberTree :: Eq a => Tree a -> StateB (Table a) (Tree Int)
> numberTree Nil = return Nil
> numberTree (Node x t1 t2)
> = do num <- atomically $ numberNode x
> nt1 <- numberTree t1
> nt2 <- numberTree t2
> return (Node num nt1 nt2)
> where
> numberNode :: Eq a => a -> State (Table a) Int
> numberNode x
> = do table <- get
> (newTable, newPos) <- return (nNode x table)
> put newTable
> return newPos

> nNode:: (Eq a) => a -> Table a -> (Table a, Int)
> nNode x table
> = case elemIndex x table of
> Nothing -> (table ++ [x], length table)
> Just i -> (table, i)
And an evaluation function:

> numTree :: (Eq a) => Tree a -> Tree Int
> numTree t = evalStateB (numberTree t) []
Some test data:

> testTree = Node "Zero" (Node "One" (Node "Two" Nil Nil) (Node "One" (Node "Three" Nil Nil) Nil)) Nil
Executing numTree testTree will produce the output:
Node 3 (Node 1 (Node 2 Nil Nil) (Node 1 (Node 0 Nil Nil) Nil)) Nil
Which is exactly what we wanted!

This code is almost exactly the same as the solution given to the in-order problem in the source to Control.State.Lazy, the only changes are the use of the function evalStateB instead of the familiar evalState, and the use of the function atomically, and the StateB monad. The implementation of these will be explained bellow.

First the API, then the implementation.

The API


We have the new monad StateB s, where s is the type of the stored state.

StateB s is an instance of MonadState s, so get and put are as expected.

There is also:

> -- runStateB :: StateB s a -> s -> (a, s)
> evalStateB :: StateB s a -> s -> a
> execStateB :: StateB s a -> s -> s

which should look familiar. The trick is that the state s passed in to these functions is the final state, and the state returned is the initial state. In the example above, remember that the last element seen in the walk was given the first label, and the first element seen in the walk was given the last.

The default implementation of modify in Control.Monad.State.Class is implemented as follows:

-- modify :: MonadState s m => (s -> s) -> m ()
-- modify f = do
-- s <- get
-- put (f s)
In the StateB monad, this code will bottom-out, because of the circular data dependency of the two monadic actions - in the backwards state monad, (>>=) passes the result forward and the state backwards, which means that the above code has a nice loop where the first line grabs the updated state from the second line and tries to pass it in as an argument to the second line.

To make this work, we need a version of modify specific to StateB:

> modifyB :: (s -> s) -> StateB s ()
But if you want to modify the state and return the result, you'll need something more sophisticated:

> atomically :: State s a -> StateB s a
atomically converts an action under the normal state monad to a single action under StateB, allowing you do do complex updates to the state easily without bottoming out (using mdo notation also works).

Implementation


The base of the implementation is taken directly from Wadler's paper.

The StateB monad is almost the same as the State monad - each action of type a is a function of type \s -> (a,s). The difference is in the implementation of (>>=).

Let's start with the monad:

> newtype StateB s a = StateB {runStateB :: s -> (a,s)}

> instance Monad (StateB s) where
> return = StateB . unitS
> (StateB m) >>= f = StateB $ m `bindS` (runStateB . f)
Because wrapping and unwrapping the newtype annoys me, all of that is confined to the exported functions (like return and (>>=)). The functions that deal directly with the underlying type all have an 'S' suffix.

> m `bindS` k = \s2 -> let (a, s0) = m s1
> (b, s1) = k a s2
> in (b, s0)

> unitS a = \s2 -> (a, s2)
As you can see, the passed in state is acted on by the RHS of bindS, the intermediate state is consumed by the LHS, and the LHS produces the final state, s0. It looks too simple to work, but it does.
And the other API functions:

> execStateB m = snd . runStateB m

> evalStateB m = fst . runStateB m

> modifyB = StateB . modify'
> where modify' f = \s -> ((), f s)

> atomically = StateB . runState
Just for funsies:

> instance Functor (StateB s) where
> fmap f m = StateB $ mapS f (runStateB m)

> mapS f m = \s -> let (a, s') = m s in (f a, s')

> instance MonadState s (StateB s) where
> get = StateB get'
> where get' = \s -> (s,s)
>
> put = StateB . put'
> where put' s = const ((),s)

> instance MonadFix (StateB s) where
> mfix = StateB . mfixS . (runStateB .)

> mfixS f = \s2 -> let (a,s0) = (f b) s1
> (b,s1) = (f a) s2
> in (b,s0)

The transformer


Now a treat for those of you still paying attention. I haven't really tested this, but it looks like it should work and that's good enough for me. A lot of this is in the style of the sources for Control.Monad.State.Lazy.

> newtype StateBT s m a = StateBT {runStateBT :: s -> m (a,s)}

> unitST a = \s -> return (a,s)

> m `bindST` k = \s2 -> mdo ~(a,s0) <- m s1
> ~(b,s1) <- k a s2
> return (b,s0)

> execStateBT :: Monad m => StateBT s m a -> s -> m s
> execStateBT m s = do ~(_,s') <- runStateBT m s
> return s'

> evalStateBT :: Monad m => StateBT s m a -> s -> m a
> evalStateBT m s = do ~(a,_) <- runStateBT m s
> return a

> modifyBT :: Monad m => (s -> s) -> StateBT s m ()
> modifyBT = StateBT . modify'
> where modify' f = \s -> return ((),f s)

> atomicallyT :: Monad m => State s a -> StateBT s m a
> atomicallyT m = StateBT $ \s-> return $ runState m s

> atomicallyTM :: Monad m => StateT s m a -> StateBT s m a
> atomicallyTM = StateBT . runStateT

> mapST f m = \s -> do ~(a,s') <- m s
> return (f a,s')

> liftST m = \s -> do a <- m
> return (a,s)

> mfixST f = \s2 -> mdo ~(a,s0) <- (f b) s1
> ~(b,s1) <- (f a) s2
> return (b,s0)

> instance Monad m => Functor (StateBT s m) where
> fmap f m = StateBT $ mapST f (runStateBT m)

> instance MonadFix m => Monad (StateBT s m) where
> return = StateBT . unitST
> (StateBT m) >>= f = StateBT $ m `bindST` (runStateBT . f)
> fail = StateBT . const . fail

> instance MonadTrans (StateBT s) where
> lift = StateBT . liftST

> instance MonadFix m => MonadState s (StateBT s m) where
> get = StateBT get'
> where get' = \s -> return (s,s)
>
> put = StateBT . put'
> where put' s = const $ return ((),s)

> instance MonadFix m => MonadFix (StateBT s m) where
> mfix = StateBT . mfixST . (runStateBT .)

Monday, July 23, 2007

ICFP '07 Post-Mortem: IV

My friend Creighton and I entered the ICFP programming competition this year, we didn't make it very far, but then again we didn't spend as much time on it as last year. That's the way it goes.

I'm posting this in the hopes that someone can point out our bug. Please, help me!

This is our main module to convert DNA to RNA. If you're familiar with this years contest (and Haskell, I suppose) it should be reasonably comprehensible. I hope. If not, please let me know.
====================
Execute.lhs



> {-# OPTIONS -fglasgow-exts #-}

> module Execute where

> import DNA
> import Control.Monad.State
> import Data.List
> import System.IO
> import System.Environment
> import Data.Maybe
> import Maybe


I don't know that I've ever even tested our "main" method, maybe Creighton has. Almost all of our testing was done by loading the Testing module into GHCI.


> main :: IO ()
> main = do
> prefile:dnafile:_ <- getArgs
> prefix <- (openFile prefile ReadMode) >>= hGetContents
> dna <- (openFile dnafile ReadMode) >>= hGetContents
> let (World rna _ ) = execState execute (World [] (prefix++dna))
> print rna
> return ()


Here are our datatypes for the template items and pattern items. Everywhere the spec uses the Template datatype, that translates to [Template] in our implementation (and similarly for Pattern). Otherwise, these are pretty much straight from the spec.


> data Template = TBase Char | NL Int Int | N Int
> deriving Show

> data Pattern = Base Char | Skip Int | Search DNA | GOpen | GClose
> deriving Show


Most of the interesting stuff happens in the state monad, and this is our state!
DNA is of type String, and RNA is of type [DNA].


> data World = World RNA DNA
> deriving (Show, Eq)


These next few function operate on our state, they let us read DNA and write RNA. They'll get used all over the place.


> peekDNA :: (MonadState World m, Integral a) => a -> m [Char]
> peekDNA n = do World _ dna <- get
> return $ genericTake n dna

> popDNA :: (MonadState World m, Integral a) => a -> m [Char]
> popDNA n = do World a dna <- get
> put $ World a (genericDrop n dna)
> return $ genericTake n dna

> pushRNA :: MonadState World m => [Char] -> m ()
> pushRNA rna = do World rnas a <- get
> put $ World (rna:rnas) a


This is the Big Deal DNA to RNA function. The idea is that you give this to execState along with a World containing no RNA and the input DNA, and you'll get back a World containing the output RNA. The "main" function above has an example of this.


> execute :: MonadState World m => m ()
> execute = runMaybeT execute' >> return ()


The function execute' is run under the MaybeT monad transformer so that we can short-circuit the process from any of our functions by calling fail, which acts like finish () in the spec.

The function execute' looks almost exactly like in the spec. The reversals are in hopes that lots of pre-pending plus one big reverse is quicker that a lot of small post-pendings.


> execute' :: MonadState World m => m ()
> execute' = do p <- liftM reverse pattern
> t <- liftM reverse template
> matchreplace p t >> execute'


> pattern :: MonadState World m => m [Pattern]
> pattern = pattern' 0 []


Again, if you're familiar with the function pattern in the contest spec, this shouldn't look at all unfamiliar. Tail recursion is used to keep track of how match pattern is built up so far, and the current level.


> pattern' :: MonadState World m => Int -> [Pattern] -> m [Pattern]
> pattern' x ps = do
> base <- popDNA 1
> case base of
> "C" -> pattern' x ((Base 'I'):ps)
> "F" -> pattern' x ((Base 'C'):ps)
> "P" -> pattern' x ((Base 'F'):ps)
> otherwise -> do
> base' <- popDNA 1
> case (base,base') of
> ("I","C") -> pattern' x ((Base 'P'):ps)
> ("I","P") -> do
> n <- nat
> pattern' x ((Skip n):ps)
> ("I","F") -> do
> popDNA 1
> s <- consts
> pattern' x ((Search s):ps)
> otherwise -> do
> base'' <- popDNA 1
> case (base,base',base'') of
> ("I","I","P") -> pattern' (x+1) ((GOpen):ps)
> ("I","I","C") -> if x==0 then return ps else pattern' (x-1) ((GClose):ps)
> ("I","I","F") -> if x==0 then return ps else pattern' (x-1) ((GClose):ps)
> ("I","I","I") -> (popDNA 7 >>= pushRNA) >> pattern' x ps
> otherwise -> fail ""

> template :: MonadState World m => m [Template]
> template = template' []


Again, this shouldn't look unfamiliar to anyone who's spent time on the contest. And again, tail recurion is used to build up the template. In retrospect I probably didn't need to pass the current list in as a param, but hey, it's done. I guess I've bought into the "tail recursion as a replacement for state" meme. I'll need to break that habit - it isn't very Haskell-ish.


> template' :: MonadState World m => [Template] -> m [Template]
> template' ts = do base <- popDNA 1
> case base of
> "C" -> template' $ (TBase 'I') : ts
> "F" -> template' $ (TBase 'C') : ts
> "P" -> template' $ (TBase 'F') : ts
> "I" -> do base' <- popDNA 1
> case base' of
> "C" -> template' $ (TBase 'P'):ts
> "F" -> do l <- nat
> n <- nat
> template' ((NL n l):ts)
> "P" -> do l <- nat
> n <- nat
> template' ((NL n l):ts)
> "I" -> do base'' <- popDNA 1
> case base'' of
> "C" -> return ts
> "F" -> return ts
> "P" -> do n <- nat
> template' $ (N n):ts
> "I" -> do pushRNA =<< popDNA 7
> template' ts
> _ -> fail ""
> _ -> fail ""
> _ -> fail ""


This is where our error is. Are there any Haskell people who did this years ICFP contest who can tell us where we went wrong? Because I'm mystified, myself, and I really wish I had a working DNA -> RNA converter. In one of the examples, the "popDNA i" in the base case never seems to get called!


> matchreplace p t= matchreplace' p t 0 [] []
> matchreplace' [] t i e c = popDNA i >> (modify $ replace t e)
> matchreplace' (p:ps) t i e c = do
> (World _ dna) <- get
> case p of
> Base b -> if dna !!! i == (Just b)
> then matchreplace' ps t (i+1) e c
> else return ()
> Skip n -> if length dna > (i + n) then return ()
> else matchreplace' ps t (i+n) e c
> Search s -> case searchPost s dna i of
> Just n -> matchreplace' ps t n e c
> Nothing -> return ()
> GOpen -> matchreplace' ps t i e (i:c)
> GClose -> matchreplace' ps t i (e++[(subseq (head c) i dna)]) (subseq' 1 c)

> searchPost :: DNA -> DNA -> Int -> Maybe Int
> searchPost s dna i = let search n [] = Nothing
> search n (s':next) = if s' == s then Just n else search (n+1) next
> in liftM ((i+length s)+) $ search 0 ((map $ take (length s)) . tails $ genericDrop i dna)


> replace t e = replace' t e []

> replace' [] e r = (\(World rna dna) -> World rna (r++dna))
> replace' (t:ts) e r = case t of
> TBase b -> replace' ts e (r++[b])
> NL n l -> replace' ts e (r++(protect l $ fromMaybe [] (e!!!n)))
> N n -> replace' ts e (r++(asnat $ length $ fromMaybe [] (e!!!n)))


The rest of this are the utility functions used by the above. They're pretty simple, and should be familiar to you if you've done this year's ICFP competion


> asnat :: Integral n => n -> DNA
> asnat n | n==0 = "P"
> | n >= 0 && n `mod` 2==0 = 'I':(asnat $ n `div` 2)
> | n >= 0 = 'C' : (asnat $ n `div` 2)

> quote :: DNA -> DNA
> quote ('I':ds) = 'C':(quote ds)
> quote ('C':ds) = 'F':(quote ds)
> quote ('F':ds) = 'P':(quote ds)
> quote ('P':ds) = 'I':'C':(quote ds)
> quote _ = []

> protect :: Integral n => n -> DNA -> DNA
> protect 0 dna = dna
> protect n dna | n > 0 = protect (n-1) (quote dna)
> | otherwise = error "Protect should never receive a negative argument"


> nat :: (MonadState World m, Integral i) => m i
> nat = do dna <- popDNA 1
> case dna of
> "P" -> return 0
> "I" -> liftM (* 2) nat
> "F" -> liftM (* 2) nat
> "C" -> liftM (\x -> 2*x+1) nat
> _ -> fail ""

> consts :: MonadState World m => m DNA
> consts = do n <- popDNA 1
> case n of
> "C" -> liftM ('I':) consts
> "F" -> liftM ('C':) consts
> "P" -> liftM ('F':) consts
> "I" -> do n' <- peekDNA 1
> case n' of
> "C" -> popDNA 2 >> liftM ('P':) consts
> _ -> return ""
> _ -> return ""


And that's it for this file!

ICFP '07 Post-Mortem: III

Welcome to my series of posts on the ICFP competion entry I worked on!

"Testing" is our testing harness. the most exciting thing here is the function "test", which is just like the function "execute" in the Execute module, except it's wrapped around the IO monad and spits out diagnostics. If you're going to try an execute our code, you're going to want this.


===================
Testing.lhs


> module Testing where

> import Control.Monad.State
> import Maybe
> import Execute
> import System.IO
> import DNA


The strings iter1 through iter3 are the DNA sequences provided in the contest docs for testing out code.


> iter1 = "IIPIPICPIICICIIFICCIFPPIICCFPC"
> iter2 = "IIPIPICPIICICIIFICCIFCCCPPIICCFPC"
> iter3 = "IIPIPIICPIICIICCIICFCFC"


This is an all-in-one function to go from DNA to RNA, all while spitting out patterns and templates as debug messages.


> test :: DNA -> IO World
> test dna = flip execStateT (World [] dna) $ runMaybeT $
> let eval = do liftIO $ putStrLn "About to execute pattern"
> p <- liftM reverse pattern
> dna <- peekDNA 51
> liftIO $ do putStrLn $ "p: " ++ (show p)
> putStrLn $ "next dna: " ++ formatDNA dna
> putStrLn $ "About to execute template"
> t <- liftM reverse template
> dna <- peekDNA 51
> liftIO $ do putStrLn $ "t: " ++ (show t)
> putStrLn $ "next dna: " ++ formatDNA dna
> putStrLn $ "About to execute matchreplace"
> matchreplace p t
> dna <- peekDNA 51
> liftIO $ do putStrLn $ "next dna: " ++ formatDNA dna
> putStrLn $ "About to go through again!"
> eval
>
> in do liftIO $ putStrLn $ "Starting DNA: " ++ (formatDNA $ take 51 dna)
> eval

> formatDNA dna =
> if length dna > 50 then (take 50 dna) ++ "..." else dna

ICFP '07 Post-Mortem: II

Next up are some helper datatypes to make our code look more like the spec. If you're familiar with the contest (which is what I'm assuming) nothing here should look strange. For those of you that aren't familiar with the contest, here's the specification (PDF).


============
DNA.lhs


> module DNA where

> import Data.List

> type DNA = String
> type RNA = [DNA]

> subseq' a = genericDrop a

> subseq a b = genericTake (b-a) . genericDrop a

> (!!!) :: [a] -> Int -> Maybe a
> dna !!! x = if x >= length dna then Nothing else Just (dna !! x)

ICFP '07 Post-Mortem: I

This is the first of a few posts outlining Creighton and myself's effort towards this years IFCP programming competition. We didn't get too far, but I've learned a lot (more) about Haskell along the way.

I plan on doing one post per module, and this first post defines the Maybe monad transformer, which isn't in GHC (yet?) but made our code look much neater.


Check it out!

=======================
Maybe.lhs


> {-# OPTIONS -fallow-undecidable-instances -fglasgow-exts #-}

> module Maybe where


Almost all of this is taken from the Haskell Wiki


> import Control.Monad
> import Control.Monad.Trans
> import Control.Monad.State

> newtype MaybeT m a = MaybeT {runMaybeT :: m (Maybe a)}

> instance Functor m => Functor (MaybeT m) where
> fmap f x = MaybeT $ fmap (fmap f) $ runMaybeT x

> instance Monad m => Monad (MaybeT m) where
> return = MaybeT . return . return
> x >>= f = MaybeT $ runMaybeT x >>= maybe (return Nothing) (runMaybeT . f)
> fail _ = MaybeT $ return Nothing

> instance Monad m => MonadPlus (MaybeT m) where
> mzero = MaybeT $ return mzero
> mplus x y = MaybeT $ liftM2 mplus (runMaybeT x) (runMaybeT y)

> instance MonadTrans MaybeT where
> lift = MaybeT . liftM return


Here are my contributions, which I shoudl proabbly give back to the wiki: the MonadIO instance and the MonadState instance. You'd think these would generalize to any instance of MonadTrans, seeing as I only use lift. I haven't tried it yet.


> instance MonadIO m => MonadIO (MaybeT m) where
> liftIO = lift . liftIO


My Haskell-fu isn't good enough to make the instance of MonadState work without -fallow-undecidable-instances. If anyone knows why, let me know.


> instance (MonadState s m) => MonadState s (MaybeT m) where
> get = lift get
> put = lift . put

Tuesday, July 10, 2007

Latex + Blogger help

I've been working on writing up my solutions to the exercises in Pierce's Basic Category Theory for Computer Scientists in this space, but I'm getting to the point where it's useful to include diagrams in my solutions.

Does anyone have any Linux-based workflows they'd like to share that could give a small JPEG if I supply a prelude and a LaTeX statement?

Friday, July 06, 2007

More from Pierce's Category Theory

Continuing the last set of exercises:

1.3.10 Exercises

4 Let f :: A -> B be an isomorphism. Show that it's inverse is unique.
First, I will suppose that the inverse of f is not unique, that is there exists two unique arrows a,b :: B -> A such that:
  • f . b = idA, b . f = idB
  • f . a = idA, a . f = idB

Therefore:
  • f . b = f . a
  • a . (f . b) = a . (f . a)
  • (a . f) . b = (a . f) . b
  • idB . b = idB . a
  • b = a
If f is an isomorphism, it's inverse is unique.

5 Show that if f' is the inverse of f :: A -> B and g' is the inverse of g :: B -> C, then (f' . g') is the inverse of (g . f).

(Notational note: In this exercise I'm using prime (') to denote inversion)

  • (g . f)' . (g . f) = idA
  • ((g . f)' . g) . f = idA
  • (g . f)' . g = f'
  • (g . f)' = f' . g' QED
6 Find a category containing an arrow that is both a monomorphism and an epimorphism, but not an isomorphism.

I don't really understand this question ... Does the category 2 satisfy this? The only non-identity arrow is trivially both epic and monic and has no inverse. So, yeah.

That's it for this bit of questions! Hopefully I can keep this up for at least the next exercise set.

Thursday, July 05, 2007

Basic Catagory Theory for Computer Scientists

I'm not in grad school anymore (which is a story!), so now I have to practice on my own time to keep my academic knife sharp.

To that end I'm working through Pierce's Basic Category Theory for Computer Scientists. So far, category theory isn't hard conceptually - but the concepts are so abstract that I find it difficult to internalize them. But then, it's not like I spent a lot of time in the math dept. back when I was in school (as much as I liked the mathematical tools I used).

Although I shouldn't be going on about how "not hard" it is while I'm still in chapter one.

Onward!

1.3.10 Exercises

2 Show that in any category, if two arrows f and g are both monic then their composition (g . f) is monic. Also, if (g . f) is monic then so is f.

The first part:
  • Let (g . f) . a = (g. f) . b
  • -> g . (f . a) = g . (f . b)
  • Because g is monic -> f . a = f . b
  • Because f is monic -> a = b
Therefore (g . f) is monic

The second part:

Suppose that (g . f) is monic.
Let's further suppose that there exists two arrows a and b such that:

f . a = f . b, a \= b

  • g . (f . a) = g . (f . b), a \=b, via arrow composition
  • (g . f) . a = (g . f) . b, a\=b, via associativity of composition
Which violates my first assumption. Therefore: If (g . f) is monic, for all pairs of arrows a and b such (f . a) = (f . b), a = b. Therefore f is monic.


3 Dualize the previous exercise: state and prove the analogous proposition for epics.

Along the same lines as the previous proof:
  1. Let (g . f) be epic.
  2. Let there exist two arrows a and b such that a . g = b . g and a \= b.
(a . g) . f = (b . g) . f, a \=b via composition of arrows
a . (g . f) = b . (g . f), a \= b via associativity of composition

My assumptions are in contradiction. Therefore, if (g . f) is epic, there exist no two arrows a and b such that a . g = b . g and a \=b - that is, g is epic.

More to come. Let me know if my math is crap.

Wednesday, July 04, 2007

Another quine

This quine is a lot like my first Haskell quine, except shorter.
(This one is technically not a quine, due to linebreaks, but it prints a quine when executed)

import System.IO
main=(putStr.map toEnum)p>>(putStr.show)p>>putStr "\n"
p=[105,109,112,111,114,116,32,83,
121,115,116,101,109,46,73,79,
10,109,97,105,110,61,40,112,
117,116,83,116,114,46,109,97,
112,32,116,111,69,110,117,109,
41,112,62,62,40,112,117,116,
83,116,114,46,115,104,111,119,
41,112,62,62,112,117,116,83,
116,114,32,34,92,110,34,10,
112,61]

Tuesday, July 03, 2007

Another quine, this time using the printf trick

I'm not sure how to make blogger give me a scrollbar to put code in.
You'll just have to remove linebreaks where needed.


import System.IO
import Text.Printf
main = let s = "import System.IO%cimport Text.Printf%cmain = let s = %c%s%c
in printf s (10 :: Int) (10 :: Int) (34 :: Int) s (34 :: Int) (10 :: Int)%c"
in printf s (10 :: Int) (10 :: Int) (34 :: Int) s (34 :: Int) (10 :: Int)

Hurrah for fixed points


import System.IO

-- My first haskell quine, revised

main :: IO ()
main = do (putStr . map toEnum) prog

(putStr . breaker . show) prog

putStr "\n"

breaker :: String -> String
breaker = (unwordsBy ',' . f . wordsBy ',') where
f xs
| length xs > 8 = (take 8 xs) ++ (f . g) (drop 8 xs)
| otherwise = xs

g [] = []
g (x:xs) = ("\n " ++ x):xs

-- Adapted from "lines" in the GHC List module
wordsBy :: Char -> String -> [String]
wordsBy _ "" = []
wordsBy c s = let (l, s') = break (== c) s in
l: case s' of
[] -> []
(_:s'') -> wordsBy c s''

-- Adapted from "unlines" in the GHC List module
unwordsBy :: Char -> [String] -> String
unwordsBy _ [] = ""
unwordsBy c ws = foldr1 (\w s -> w ++ c:s) ws

prog :: [Int]
prog = [105,109,112,111,114,116,32,83,
121,115,116,101,109,46,73,79,
10,10,45,45,32,77,121,32,
102,105,114,115,116,32,104,97,
115,107,101,108,108,32,113,117,
105,110,101,44,32,114,101,118,
105,115,101,100,10,10,109,97,
105,110,32,58,58,32,73,79,
32,40,41,10,109,97,105,110,
32,61,32,100,111,32,40,112,
117,116,83,116,114,32,46,32,
109,97,112,32,116,111,69,110,
117,109,41,32,112,114,111,103,
10,10,32,32,32,32,32,32,
32,32,32,32,40,112,117,116,
83,116,114,32,46,32,98,114,
101,97,107,101,114,32,46,32,
32,115,104,111,119,41,32,112,
114,111,103,10,10,32,32,32,
32,32,32,32,32,32,32,112,
117,116,83,116,114,32,34,92,
110,34,10,10,98,114,101,97,
107,101,114,32,58,58,32,83,
116,114,105,110,103,32,45,62,
32,83,116,114,105,110,103,10,
98,114,101,97,107,101,114,32,
61,32,40,117,110,119,111,114,
100,115,66,121,32,39,44,39,
32,46,32,102,32,46,32,119,
111,114,100,115,66,121,32,39,
44,39,41,32,119,104,101,114,
101,10,32,32,102,32,120,115,
10,32,32,32,32,124,32,108,
101,110,103,116,104,32,120,115,
32,62,32,56,32,61,32,40,
116,97,107,101,32,56,32,120,
115,41,32,43,43,32,40,102,
32,46,32,103,41,32,40,100,
114,111,112,32,56,32,120,115,
41,10,32,32,32,32,124,32,
111,116,104,101,114,119,105,115,
101,32,32,32,32,32,61,32,
120,115,10,10,32,32,103,32,
32,91,93,32,32,32,32,61,
32,91,93,10,32,32,103,32,
40,120,58,120,115,41,32,61,
32,40,34,92,110,32,34,32,
43,43,32,120,41,58,120,115,
32,10,10,45,45,32,65,100,
97,112,116,101,100,32,102,114,
111,109,32,34,108,105,110,101,
115,34,32,105,110,32,116,104,
101,32,71,72,67,32,76,105,
115,116,32,109,111,100,117,108,
101,10,119,111,114,100,115,66,
121,32,58,58,32,67,104,97,
114,32,45,62,32,83,116,114,
105,110,103,32,45,62,32,91,
83,116,114,105,110,103,93,10,
119,111,114,100,115,66,121,32,
95,32,34,34,32,61,32,91,
93,10,119,111,114,100,115,66,
121,32,99,32,115,32,32,61,
32,108,101,116,32,40,108,44,
32,115,39,41,32,61,32,98,
114,101,97,107,32,40,61,61,
32,99,41,32,115,32,105,110,
10,32,32,32,32,32,32,32,
32,32,32,32,32,32,32,32,
108,58,32,99,97,115,101,32,
115,39,32,111,102,10,32,32,
32,32,32,32,32,32,32,32,
32,32,32,32,32,32,32,32,
32,32,91,93,32,32,32,32,
32,32,45,62,32,91,93,10,
32,32,32,32,32,32,32,32,
32,32,32,32,32,32,32,32,
32,32,32,32,40,95,58,115,
39,39,41,32,45,62,32,119,
111,114,100,115,66,121,32,99,
32,115,39,39,10,10,45,45,
32,65,100,97,112,116,101,100,
32,102,114,111,109,32,34,117,
110,108,105,110,101,115,34,32,
105,110,32,116,104,101,32,71,
72,67,32,76,105,115,116,32,
109,111,100,117,108,101,10,117,
110,119,111,114,100,115,66,121,
32,58,58,32,67,104,97,114,
32,45,62,32,91,83,116,114,
105,110,103,93,32,45,62,32,
83,116,114,105,110,103,10,117,
110,119,111,114,100,115,66,121,
32,95,32,91,93,32,61,32,
34,34,10,117,110,119,111,114,
100,115,66,121,32,99,32,119,
115,32,61,32,102,111,108,100,
114,49,32,40,92,119,32,115,
32,45,62,32,119,32,43,43,
32,99,58,115,41,32,119,115,
10,10,112,114,111,103,32,58,
58,32,91,73,110,116,93,10,
112,114,111,103,32,61,32]

Listening:

Watching:

  • House
  • Ride Back