Translate Haskell into English Manually, Part II

Write a program in Haskell that translates C type declarations into English.

I'd like to thank the readers of the haskell-cafe mailing list for taking the time to read and critique my code. I received comments from Benjamin Franksen, Bill Wood, Brian Hulley, Bulat Ziganshin, Jean-Philippe Bernardy, Malcolm Wallace, Pete Chown, Scott Turner, Tomasz Zielonka and Udo Stenzel. I received extensive feedback from Daniel Fischer and Neil Mitchell. I'd also like to thank my friends for their technical reviews: Anuranjan Shukla, Brandon L. Golm (who turns my Engrish into English), Brennan Evans, Christopher Golden, Krishna Srinivasan and Sam Rushing. In particular, Jared Updike was a great source of help throughout the entire process.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Good static typing does make a gidfference.

Curt Sampson's picture

As background: my first five years of full-time programming were Java, the next five years after that, Ruby, and over the last year or so I've moved to nearly-full-time Haskell.

Types in Haskell do often feel like a nuisance when you come from a Ruby background, especially when you're doing quick-and-dirty hacks where you're not so concerned about correctness because you're going to throw out the code after a few uses.

However, these days I just as often find the lack of types in Ruby to be more of a nuisance because I have to work fairly hard to keep silly bugs from creeping into my programs (oops, that was supposed to be an array of arrays, not an array) whereas in Haskell the type checker deals with all of this for me. In Haskell I find myself using far fewer unit tests and doing both small and large refactorings with more confidence. I also find I no longer need to use error checking code as I did on occasion in Ruby, where I'd look at a situation and say to myself, "if the wrong class of object gets out of here, it's going to appear half-way across the program and I'll spend ages debugging it."

Not to mention which, when you really start using monads and combinators, you'll find them extremely powerful.

it's unfair to blindly translate algorithms

Shannon -jj Behrens's picture

Brandon Moore has sent me an alternate version of the code that is both simple and yet still shorter than the C version. His findings suggest that an algorithm in C may not translate easily or naturally into Haskell; which, of course, is not surprising. I purposely made the Haskell program as close to the C program as possible to aid the reader in understanding it, but perhaps this was an unfair handicap to Haskell.

Alternate solution

Brandon Moore's picture

I wrote some alternate code which makes a simple parser monad, rather than the simple state monad used in the article. It's like a recursive descent parser, but with all the recursion wrapped up inside the monad. This doesn't quite handle quantifiers like const and static at the beginning of the declaration correctly, but the C and Haskell code are already both wrong in different ways, and the full syntax is really complicated so I don't care. I count 62 lines of code.

Many thanks for a very clear

Jim B's picture

Many thanks for a very clear tutorial. I'm some way from grokking monads but this should help...As you say, introductory articles on monads are usually a bit deep (The subtitle of the Programmers Guide to Monads, 'Don't Panic', sounds promising but 2 or 3 pages later sure enough I was panicking!) so congratulations on not mentioning Category Theory :-)

Your link to the syntax tour is broken. I suppose it's meant to be but that gives a 404 - another place is but I don't know if this is it's home.


Shannon -jj Behrens's picture

Thanks for your comment as well as mentioning the broken link.