First of all, thank you all so much for taking the time to help me with this exercise! My hope is that once I'm able to understand it, my understanding can come through in the article I write.
> Brian Hulley: > In the pipe in the 'otherwise' branch, at the moment you have to > assume that each of the transformations can successfully be done. > What happens if getToken can't get a token because there are no more > tokens left? To solve this problem you could use a monad such as > Maybe, to encapsulate the strategy "keep going as long as no > problems have been encountered so far" eg: I can see where you're going with the Maybe monad, and it does make sense. However, I see Maybe as a "hammer" for a nail I wasn't really all that interested in nailing ;) It's true that getToken might fail. Most of the program isn't prepared to handle errors gracefully, but neither was the C version. That's okay. If anything, handling it as an exception and printing out a generic error message would be more than enough. Aside from the better error handling, I fear the Maybe monad isn't buying much. > Bulat Ziganshin: > what you need here, imho, is a state monad. > Danil Fischer > I'd use a State-monad, say I suspect you guys are right. I had always thought of states as being "isomorphic" to integers (i.e. you can be in state 0, state 1, ... state n), not as contexts (you have this input, that output, and this token stack), am I wrong? I suspect I need to spend more time trying to understand the state monad. I must admit that I baulked the last time I tried to squeeze it into my head. I'll just need to try again ;) > but if you'd done it monadically from > the start, you'd probably chosen a different design I specifically chose not to have a radically different design because I wanted to maintain the "nature" of the original C code. Naturally, if I were to try to do this from scratch, I'd use a powerful lexer and parser. However, the beauty of this code (i.e. the original C code) is that it works without *needing* to use or understand such powerful tools. > As another method, I've hacked up a translation by parsing a > declaration and creating a customized Show-instance. Yeah, I thought of that too, but decided against if for the reason given above. Think of camping--sometimes it's fun to "rough it". Sometimes it can be fun to solve this problem without powerful tools. Maybe I'm just being silly ;) > "In My Egotistical Opinion, most people's C programs should be > indented six feet downward and covered with dirt." Yeah, yeah ;) I'm mostly a Python guy, so you're preaching to the choir ;) Thanks again, guys!!! _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe