K&R Challenge 2: The Specter of Undefined Behavior
Continuing with the K&R Challenge, today we’ll be doing exercise 2:
Experiment to find out what happens when
printf‘s argument string contains\c, wherecis some character not listed above.
Basically, we’ll be trying to print “\c” to the screen, and seeing what C does.
In C
The code for this is very simple:
int main (int argc, char ** argv)
{
printf("Trying to print: \c\n");
return 0;
}Like last time, we’ll compile it using:
gcc -Wall ex2.c -o ex2Right away, you should get a compiler warning:
ex2.c: In function ‘main’:
ex2.c:10:11: warning: unknown escape sequence: '\c' [enabled by default]
printf("Trying to print: \c\n");Notice that it is a warning, not an error, and that the compilation still succeeded and produced an executable. My friends, you have just witnessed Undefined Behavior. Undefined behavior is one of the defining aspects of C. Technically, it’s a feature, not a bug, and it is both a blessing and a curse.
It’s a blessing in that it’s one of the things that enables C’s unmatched performance. It’s a curse in that the compiler is allowed by the spec to do whatever it wants when it encounters undefined behavior: it could do something really helpful, it could segfault, or it could delete your hard drive. It could even unleash lions in your house and there’s nothing the police or congress could do about it.
Moral of the story: don’t use undefined behavior unless you really know what you’re doing. Even then, I’d argue it’s a code smell.
So, what happens when you run the compiled executable? Always fearless in the pursuit of truth, I ran it. The following was printed to the console:
Trying to print: cThe GNU C Compiler decided to be nice and just strip the “\”, then print the message. It’s a good thing I have managed to avoid angering Richard Stallman, because gcc could very well have kidnapped my wife. That would have been a problem.
And In Haskell
Nothing about this exercise relies on the behavior of printf, therefore even though Haskell has it, I’ve elected not to use it. The implementation of this exercise in Haskell looks like this:
main :: IO ()
main = putStrLn "Trying to print: \c\n"As before, this can be run using:
runhaskell ex2.hs…but when you try it, the following error is displayed, and compilation fails:
ex2.hs:2:62:
lexical error in string/character literal at character 'c'Where C allowed the undefined escape sequence as undefined behavior, Haskell throws a compilation error. This is a Good Thing. Undefined behavior is a prolific source of bugs, and while I understand why it’s allowed, I can’t say that I agree that the tradeoff is worth it. Luckily for us, this isn’t a feature unique to Haskell. Most high level languages don’t have undefined behavior. Unfortunately, this is one of the reasons that most programming languages are orders of magnitude slower than C.
Regardless, undefined behavior is a fact of life for the C programmer. It’s one of the tradeoffs they make to use the language. These design decisions were made decades ago, and are unlikely to change. For this reason, this is a good exercise.
The families of those who were turned to stone by their compilers after doing this exercise are in our prayers…
Introducing The K&R Challenge
Recently, I inherited a copy of The C Programming Language, aka “K&R”. I was borrowing it, and today I tried to give it back, but the book’s former owner didn’t want it back. I was going to put it back in it’s deep dark box, likely to never been seen again, when I had a thought. Surely there’s something in this ancient tome of knowledge waiting for me.
On a whim, I decided to go through the exercises. This post marks the first task in the K&R Challenge.
The rules: the book is about the C programming langauge. The book is not about glib, linux programming, gtk, or any other library or framework. Therefore, the solutions to the exercises should only use the standard library, unless the book specifically calls out a library. I will attempt to stay as true to the wording of the excercise as possible.
Seems pretty straightforward, right? Well this brings us to part two; after doing an excercise in C, I will do it in Haskell. For these examples, I will attempt to implement the program in idiomatic Haskell. The ends are more important than the means here, so if the example calls out a specific function or technique, I will only use it if I feel it’s the best way to do it. For the Haskell portion, I will minimize the use of libraries as well.
So, without further ado…
Excercise 1.1
Excercise 1.1 is simply to implement “Hello World” Shockingly this is a trivial problem in C:
#include "stdio.h"
int main (int argc, char ** argv)
{
printf("Hello World!\n");
return 0;
}First, we include stdio.h to gain access to printf, then we say hello to the world. You’ll notice I put curly braces on their own lines. Sue me.
To compile this, assuming you’re using gcc, enter the following:
gcc -Wall ex1.c -o ex1Running the produced program produces the output:
Hello World!Amazing!
In Haskell, this is even easier:
main :: IO ()
main = putStrLn "Hello World!"As putStrLn and the IO monad are in prelude, this program does not require any imports.
To run this, simply type the following at the prompt:
runhaskell ex1.hsWhich produces the following output:
Hello World!If you were able to follow all of that, then congratulations! You are an elite hacker! Your black fedora is in the mail.
Happstack’s “Helpful” Exception Handler: A Better Solution
Recently I wrote about Happstack’s mismanagement of exceptions. I offered up a solution thab basically amounted to swallowing the exception and returning mzero. As a follow-up to that post, I’d like to offer a better solution.
I believe Happstack is on the right track. An uncaught exception does in fact represent an internal server error, not a file not found, however Happstack misses the mark in a few ways. First, it prints the exception message, which for reasons I went into last week, is bad. And second, it doesn’t provide a mechanism to override this behavior.
It was suggested to me that I could place a monad on top of the ServerPartT transformer stack that re-implements fail. This represents a few issues for me. If I were to do this, I wouldn’t be able to use the basic ServerPart monad, greatly complicating my code as this locks me out of all library functions that take this type. Secondly, it’s an unnessesary level of indirection. Why should I add a monad to the stack that does nothing except re-implement fail? Why can’t I configure Happstack to use a custom exception response?
So, What Are You Going To Do About It?
Good question. I’ve come up with a solution that I’m fairly satisfied with. At the heart of this issue are IO actions that throw exceptions. To perform an IO action inside of a ServerPart, you must lift ServerPart‘s IO monad. This is done like so:
foo <- liftIO $ barThis snippet executes the IO action bar and binds its result to foo. Since, typically speaking, only IO actions throw, this represents a good place to start working. We can insert a call to try here, but this can get tedious given enough IO actions. Why don’t we create a function?
tryIO :: Maybe (SomeException -> ServerPart Response)
-> IO a
-> ServerPart a
tryIO mf io = do result <- liftIO $ try io
case (result) of Right good -> return good
Left exception -> handle exception mf
where handle exception (Just handler) = escape $ handler exception
handle _ Nothing = mzeroMeet my tryIO function. This function wraps liftIO and try into one nice and neat function. It even takes an optional response generator. Let’s take a look at this bit-by-bit.
tryIO :: Maybe (SomeException -> ServerPart Response)
-> IO a
-> ServerPart aThis function takes a function that takes a SomeException, and returns a ServerPart Response. This function is wrapped in a Maybe. The function also takes an IO action, and returns a ServerPart a. Basically, this works like a specialized version of liftIO. Unlike a vanilla liftIO, it can take an optional exception handler.
tryIO mf io = do result <- liftIO $ try io
case (result) of Right good -> return good
Left exception -> handle exception mfHere we have the meat of this function. First, the IO action is wrapped in a call to try. Next this is promoted to a ServerPart via the call to liftIO. The result of this will be Either a SomeException, or a valid result. We use a case statement to examine the result, and either return the good result, or call handle and pass it the exception and the exception handler.
where handle exception (Just handler) = escape $ handler exception
handle _ Nothing = mzeroFinally, we handle the exception. If an exception handler was passed in, it’s called, and then the response is returned to Happstack via escape. If no handler was passed in, the function returns mzero.
The function escape is very useful here. This function is basically like returning mzero, only instead of the response handler failing, it returns a ServerPart Response immediately. This allows you to break out of a deeply nested function easily without having to manually return from each function.
The result
The result of this new function is that I can use tryIO as I would have used liftIO in a ServerPart function. I can either call…
foo <- tryIO Nothing bar…and have my response handler fail with mzero if an exception is thrown, or I can call…
foo <- tryIO (Just baz) bar…and have my response handler fail and return the result of baz. baz could even do some cleanup and try to call the initial response handler over again if it wanted to! Currently, when an IO action fails in my application, users see this lovely error message:
Much better. Unless you’re a hacker!
Happstack’s “Helpful” Exception Handler
Lately I’ve been messing around with web development in Haskell using Happstack. I believe that web development is something that a pure functional language excels in. Web apps are inherently stateless, so it stands to reason that a stateless programming language would be a good fit.
Happstack provides many of the nice features one would expect of a web framework. Among these things is a top-level exception handler to prevent exceptions from bringing down the server. Suppose you try to call head on an empty list:
willThrow :: ServerPart Response
willThrow = ok $ head []This will of course throw an exception. Happstack “helpfully” catches it and produces this output:
Why the air quotes? Notice how Happstack prints the exception message? While this might seem somewhat benign with a simple empty list exception (maybe even helpful if you’re troubleshooting), imagine you’re doing something a little less contrived:
maliciousThrow :: ServerPart Response
maliciousThrow = do dirs <- liftIO $ getDirectoryContents
"/bar"
ok $ toResponse $ show $ dirsOnce again Happstack airs out your dirty laundry.
In this case, it prints the fact that /bar doesn’t exist for the whole world to see. Great…
I spent some time searching around for the proper way to deal with exceptions in Happstack. There doesn’t seem to be much other than “handle them”. Personally, I feel that if an unhandled exception is thrown, Happstack should treat it as mzero.
This can be accomplished pretty simply:
noThrow :: ServerPart Response
noThrow = do dirs <- liftIO $ tryGDC "/bar"
case (dirs) of Right d -> ok $ toResponse $ show $ d
Left _ -> mzero
where tryGDC :: String -> IO (Either SomeException [FilePath])
tryGDC a = try $ getDirectoryContents aThis function is similar to the previous maliciousThrow, except for the tryGDC function. This function uses the try function found within Control.Exception. Try attempts to perform some IO action, and returns Either an exception or a result, wrapped within an IO.
It is necessary to give tryGDC a function signature. Since functions can throw multiple exception types, the type checker cannot infer which is correct. In this case I’ve used the top-level exception class SomeException.
After trying, I check the result. On Right I return a ServerPart Response, on Left, I return mzero. Now when I attempt to access the page using this new version of maliciousThrow, I get this:
As it should be. It’s nobody’s business what went wrong.
Best Practices
It should be noted that the function noThrow is equivalent in quality to the following snippet of Java:
public static ThingDoer newThingDoer ()
{
try
{
return ThingDoerFactory.constructThingDoer();
}
catch (Exception ex)
{
return null;
}
}If you wrote that in a real application, you would be a Bad Person. Similarly, noThrow discards all info about what went wrong. You really should do something with it. Don’t show it to the user, but log it somewhere.
Update: I’ve posted a follow-up to this article, which can be found here!
DMP Photo Booth 1.0
Well, the day has come and gone. DMP Photo Booth’s final test on June 21st went off without issue, and DMP Photo Booth has left Beta and is now considered “production ready”. The initial 1.0 release can be found on GitHub.
The significance of June 21st is the very reason DMP Photo Booth was created; the 21st is the day of my wedding. My wife wanted a photo booth for the reception. We looked into renting a photo booth, but it turns out that they run around $1,000. I turned to open source. Some quick googling turned up some options, but they were all personal projects or out of date. Sure I could get somebody else’s project working, but what’s the fun in that? I decided that we didn’t need to rent one, or download one, I could build it!
In late 2013, I set to work in earnest. I had a couple of months of downtime in school, and since I’m not currently working it was the perfect time. I decided I had three main objectives for this project: get some arduino experience, get some GTK+ experience, and do this all as portably as possible. I had initially decided to mostly ignore GLib and focus on GTK, but slowly I grew to appreciate GLib for what it is: the standard library that C never had. First I used GModule to handle shared libraries in a portable manner. Next I decided to use GLib primitives to keep from having to deal with cross-platform type wonkiness. Next, having grown tired of dealing with return codes, I refactored the project to use GLib’s exception replacement: GError.
Lessons Learned
It’s not all roses and puppies though. There are certainly things I’d do differently. DMP Photo Booth is developed in an Object Oriented style, passing opaque structs with “method” functions that operate on them. Each component of the program are organized into their own source file with file scoped globals scattered throughout. Said globals are protected by mutexes to create a semblance of thread safety. That said, threading issues have been a major thorn in my side. Long story short: I regret this design choice. While I still feel that this is the correct way to structure C code, and that if globals are required, this is the correct way to handle them; I feel that I should have made more of an effort to limit side effects. Recently, I’ve spent some time doing functional programming, and if I could do it again I’d try to write in a more functional style. Fortunately for me, this is something that a little refactoring could help with.
Additionally, one thing I thought would be a major help is something that began to be a major thorn in my side: NetBeans. As the size of the project grew, NetBeans got slower and slower. It seemed that I spent more time fiddling with IDE settings than actually coding. Even worse is that the IDE-generated makefile is so convoluted that it’s extremely difficult to modify by hand in a satisfying way. I’ve always coded with and IDE so I wouldn’t have even considered not using one, but then I spent some time with Haskell. One of Haskell’s “problems” is that it doesn’t have good IDE support. It doesn’t seem like any IDE really handles it well, so most people use Emacs. Personally, I haven’t really warmed up to Emacs, but GEdit has syntax highlighting for Haskell and a built-in terminal for GHCI. GEdit also has syntax highlighting for C. Next time, I will seriously consider using a lighter-weight text editor for a C project. All this said, I think NetBeans for Java remains the way to go.
What’s Next
Like any program, version 1.0 is just one of many versions. There certainly remains a lot of work to do with DMP Photo Booth. Some major items you are likely to see whenever I get around to working on DMP Photo Booth some more:
Options Dialog
I think anybody who has seen it will agree: the options dialog in DMP Photo Booth is bad. It’s poorly organized, and kind of wonky. Personally, I modify settings using the .rc file, which is telling. This is certainly a high-priority improvement.
Functional Refactor
Like I said above, the code could use a pass to limit side effects. Funtions need to have their side effects limited, and globals need to be eliminated unless absolutely necessary. However, C is not a functional language. While one could argue that function pointers enable functional programming in C, this is a very pedantic argument. I won’t be going crazy with functional programming techniques. There will be no Monads, or for loops being turned into mappings of function pointers.
Optional Module API
An idea I’ve had on the back burner for a while is an optional module API. This would be used for very specific quality-of-life things. For instance, a module could provide a GTK widget to be shown in the options dialog. Any module that doesn’t want to implement any or all of the optional API can just ignore it. The module loading function will gracefully handle the dlsym failure, just treating it as it is: declining to implement the API. I have no plans to change the current existing API, so all you module developers can rest easy!
User Interface Module
It occurred to me that it might be good to have a UI module. This would provide the UI, and wouldn’t be tied to the trigger/printer/camera module start/stop system. This module would be loaded at startup and unloaded on shutdown. This would allow the Photo Booth to use different widget toolkits: QT, Curses, Cocoa, WinForms, or whatever else. Under this scheme, the current GTK+ interface would be abstracted into the reference UI Module.
DMP Photo Booth: Release Candidate 1
It’s been a long time coming, but the day is almost here: the day DMP Photo Booth is officially released.
Following last week’s successful stress test, I’ve been doing some last-minute touch-up work. I’ve been preparing my laptop for the big day, and finding and squashing some bugs.
DMP Photo Booth RC1 using my fancy new dark GTK theme
Now things are coming along, and I feel the time has come to proceed to RC1. This means that barring any major new show stoppers, DMP Photo Booth will proceed to version 1.0 on June 22.
You can find the latest release here. On that page you’ll find the latest source for DMP Photo Booth and the reference modules, as well as a pre-compiled version for Debian/AMD64. Just extract the tarball into a folder and double-click the executable and you’re off! It comes pre-configured with sane defaults.
Moving forward, I plan to work on a “GTK Trigger Module”. This will just show a window with a button you can click to trigger the photo session. I understand that not everybody feels like constructing an Arduino thingamabober, and that this is surely the only thing preventing DMP Photo Booth from going viral on a global scale. Hopefully this is done by 1.0, but if not it will likely make it into a version 1.0.1, to be released shortly after 1.0.
DMP Photo Booth: To The Test
It’s been a long year leading up to this, but last week DMP Photo Booth saw its first time out in the wild.
Last weekend my fiancée had her bachelorette party. Since it was No Boys Allowed, I wouldn’t be able to babysit the Photo Booth. Luckily for me the event went off largely without issue.
I spent the week leading up to the event writing documentation. Channeling my past life as an IT professional, I wrote up an HTML page documenting the use of the Photo Booth and some common issues. This documentation will probably get uploaded to either this site or github soon. I need to strip out some stuff specifically relating to my computer first.
After that and a quick walkthrough the night before, it was go time. As the appointed hour arrived, I watched my phone for calls. The good news is that none came. The Photo Booth performed as advertised, with only a few minor difficulties caused by my computer. The only issue with the actual Photo Booth itself that was reported to me is that there is a slight delay between a picture being taken and the trigger counting down. An issue has been opened against this in Github.
The final stretch is here now. The wedding is on the 21st, and the Photo Booth must be complete by then. Honestly, if the day were tomorrow I’d be confident the Photo Booth would work. However, there is always room for polish. There remains bugs to be squashed, documentation to be finalized, and packaging to be done.
Maybe I Should Be In The Maybe Monad
If you’ve spent any time with Haskell, then you’ve surely encountered Maybe. Maybe is Haskell’s version of testing your pointer for NULL, only its better because it’s impossible to accidentally dereference a Nothing.
You’ve also probably thought it was just so annoying. You test your Maybe a to ensure it’s not Nothing, but you still have to go about getting the value out of the Maybe so you can actually do something with it.
The Problem
Let’s forgo the usual contrived examples and look at an actual problem I faced. While working on the Server Console, I was faced with dealing with a query string. The end of a query string contains key/value pairs. Happstack conveniently decodes these into this type:
[(String, Input)]I needed to write a function to lookup a key within this pair, and return it’s value. As we all know, there’s no way to guarantee that a given key is in the list, so the function must be able to handle this. There are a few ways we could go about this, but this seems to me to be an ideal place to use a Maybe. Suppose we write our lookup function like so:
lookup :: Request -> String -> Maybe StringThis is logically sound, but now we have an annoying Maybe to work with. Suppose we’re working in a ServerPart Response. We might write a response function like so:
handler :: ServerPart Response
handler = do req <- askRq
paths <- return $ rqPaths req
page <- return $ lookup req "page_number"
case page of Nothing -> mzero
(Just a) -> do items <- return $ lookup req "items_per_page"
case items of Nothing -> mzero
(just b) -> h' paths a bYucky! After each call to lookup, we check to see if the call succeeded. This gives us a giant tree that’s surely pushing off the right side of my blog page. There must be a better way.
Doing It Wrong
Shockingly, this is not the best way to do this. It turns out that writing our functions in the Maybe monad is the answer. Take the following function:
hTrpl :: Request -> Maybe ([String], String, String)
hTrpl r = do paths <- return $ rqPaths r
page <- lookup r "page_number"
items <- lookup r "items_per_page"
return (paths, page, items)… now we can re-write handler like so:
handler :: ServerPart Response
handler = do req <- askRq
triple <- return $ hTrpl req
case triple of Nothing -> mzero
(Just (a, b, c)) -> h' a b cMuch better, right? But why don’t we have to test the return values of lookup? The answer to that question lies in the implementation of Maybe‘s >>= operator:
instance Monad Maybe where
(Just x) >>= k = k x
Nothing >>= _ = NothingRecall that do notation is just syntactic sugar around >>= and a whole bunch of lambdas. With that in mind, you can see that we are actually binding functions together. Per Maybe‘s bind implementation, if you bind Just a to a function, it calls the function on a. If you bind Nothing to a function, it ignores the function, and just returns Nothing.
What this means for us is that so long as we’re inside the Maybe monad, we can pretend all functions return successful values. Maybe allows us to defer testing for failure! The first time a Nothing is returned, functions stop getting called, so we don’t even have to worry about performance losses from not immediately returning from the function! So long as we’re inside of Maybe, there will be Peace On Earth. We code our successful code branch, and then when all is said and done and the dust has settled, we can see if it all worked out.
Next time you find yourself testing a Maybe more than once in a function, ask yourself: should I be in the Maybe monad right now?
Things That Would Have Been Nice To Know: Happstack Requests
Stop me if you’ve heard this one before; after trying and failing to find an existing way to some task, a programmer gives up and creates their own method. No sooner than they’ve finished, they find the existing method. This happened to me.
Flash back a week. I’m sitting here working on my on-again-off-again project for a web app to access my home server. I’m trying to implement an image gallery application, and I need a method to read the URI and return images.
Happstack, my framework of choice, provides two methods for routing. There is some template-haskell magic that I don’t care to deal with, and there is string routing combinators. These combinators look like this:
routeFn = dir "foo" $ dir "bar" $ fooBarRouteFnBasically, routeFn tests to see if the requested path is /foo/bar, and if so, calls the fooBarRouteFn route function. This is all fine and good for simple static routes, but I want to be able to request an arbitrary path on my server, and this solution won’t work. Looking through the Happstack documentation, I find a function called uriRest that “grab[s] the rest of the URL (dirs + query) and passes it to your handler”. Using this, if I request:
http://localhost:8000/foo/bar?foo=bar… and I call uriRest, I’ll get:
"foo/bar?foo=bar"I can then use Parsec to parse that into a usable data structure. Less than ideal, but something I can work with. So, work with it I did, implementing a parser to turn that into:
data URITail = URITail {getRouteDirs :: [String],
getQueries :: Maybe [(String, Maybe String)]
} deriving (Show)This worked, though I wouldn’t call it “elegant”. I couldn’t shake the feeling I was doing it wrong. It turns out that I was.
Just Use askRq, Dummy!
It turns out that in any ServerPart, you can call askRq. This returns the Request. Request has a bunch of useful functions, here are a few of particular interest:
rqPaths
rqPaths returns a list of path segments. Exactly what would have been in my URITail‘s getRouteDirs field.
rqInputsQuery
rqInputsQuery returns a list of key-value pairs for each part of the QUERY_STRING. This is exactly what my URITail‘s getQueries field was for. Even better is the fact that this function handles all sorts of encoding issues that I, a web developer with hours of experience, wasn’t even aware of!
and others
Aside from these big two, there are functions to get the request method, get the requesting host, and all sorts of potentially useful information.
Don’t I Feel Silly?
Yeah, but it wouldn’t be the first time. I was pretty proud of my URITail module too, unfortunately it’ll have to languish in the dust bin, serving only as a learning experience. Luckily for you, you can learn from my mistakes.
If you want to route in a dynamic manner in Happstack, feel free to call askRq, and examine the request. Don’t re-invent the wheel.
Yet Another Aeson Tutorial
Lately I’ve been trying to make sense of Aeson, a prominent JSON parsing library for Haskell. If you do some googling you’ll see two competing notions: 1) Aeson is a powerful library, but it’s documentation is terrible and 2) about 10,000 Aeson tutorials. Even the Aeson hackage page has a huge “How To Use This Library” section with several examples. These examples usually take the form of:
“Make a type for your JSON data!”
data Contrived = Contrived { field1 :: String
, field2 :: String
} deriving (Show)“Write a FromJSON instance!”
instance FromJSON Contrived where
parseJSON (Object v) = Contrived <$>
v .: "field1" <*>
v .: "field2"“Yay!!”
I’ll spare you the long form, other people have done it already and I’m sure you’ve seen it already. What I quickly noticed was that this contrived example wasn’t quite cutting it. I’ve had some challenges that I’ve had to overcome. I’d like to share some of the wisdom I’ve accumulated on this subject.
Nested JSON
The first Problem I’ve run into is the nested JSON. Let’s take a look at an example:
{
"error": {
"message": "Message describing the error",
"type": "OAuthException",
"code": 190 ,
"error_subcode": 460
}
}That is an example of an exception that can get returned by any Facebook Graph API call. You’ll notice that the exception data is actually contained in a nested JSON object. If passed to a parseJSON function, the only field retrievable by operator .: is “error”, which returns the JSON object. We could define two types and two instances for this like:
data EXTopLevel = EXTopLevel { getEx :: FBException
} deriving (Show)
data FBException = FBException { exMsg :: String
, exType :: String
, exCode :: Int
, exSubCode :: Maybe Int
} deriving (Show)
instance FromJSON EXTopLevel where
parseJSON (Object v) = EXTopLevel <$>
v .: "error"
instance FromJSON FBException where
parseJSON (Object v) = FBException <$>
v .: "message" <*>
v .: "type" <*>
v .: "code" <*>
v .:? "error_subcode"In this case, you could decode to a EXTopLevel, and call getEx to get the actual exception. However, it doesn’t take a doctor of computer science to see that this is silly. Nobody needs the top-level object, and this is a silly amount of boilerplate. The solution? We can use our friend the bind operator. Aeson Objects are instances of Monad, and it turns out that it’s bind function allows us to drill down into objects. We can re-implement that mess above simply as:
data FBException = FBException { exMsg :: String
, exType :: String
, exCode :: Int
, exSubCode :: Maybe Int
} deriving (Show)
instance FromJSON FBException where
parseJSON (Object v) = FBException <$>
(e >>= (.: "message")) <*>
(e >>= (.: "type")) <*>
(e >>= (.: "code")) <*>
(e >>= (.:? "error_subcode"))
where e = (v .: "error")Much better right? I thought so too.
Types With Multiple Constructors
The next problem I’d like to talk about is using types with multiple constructors. Let’s take a look at an example:
{
"value": "EVERYONE"
}When creating a new album of facebook, the API needs you to set a privacy on the album. This setting is set using this JSON object. This would seem to be a trivial case for Aeson:
data Privacy = Privacy { value :: String
} deriving (Show)
instance FromJSON Privacy where
parseJSON (Object v) = Privacy <$>
v .: "value" <*>Unfortunately, the following is not a valid privacy setting:
"{
"value": "NOT_THE_NSA"
}However, our Privacy type would allow that. In reality, this should be an enumeration:
data Privacy = Everyone |
AllFriends |
FriendsOfFriends |
SelfBut how would you write a FromJSON instance for that? The method we’ve been using doesn’t work, and parseJSON takes and returns magical internal types that you can’t really do anything with. I was at a loss for a while, and even considered using the method I posted above. Finally, the answer hit me. Like many things in Haskell, the answer was stupidly simple; just define a function to create the privacy object, and use that in the parseJSON function instead of the type constructor! My solution looks like this:
instance FromJSON Privacy where
parseJSON (Object v) = createPrivacy v .: "value"
createPrivacy :: String -> Privacy
createPrivacy "EVERYONE" = Everyone
createPrivacy "ALL_FRIENDS" = AllFriends
createPrivacy "FRIENDS_OF_FRIENDS" = FriendsOfFriends
createPrivacy "SELF" = Self
createPrivacy _ = error "Invalid privacy setting!"If the parseJSON needs a singular function to create a type, and you have more than one type constructor for your type, you can wrap your type constructors in one function that picks and uses the correct one. Your type function doesn’t need to know about Aeson; Aeson magically turns it’s parser into whatever type your function calls for.
Doing My Programming... 