Cool, now we have something to work with. However at such a high level no paradigm's differences (much less pros/cons) would be apparent. Would you mind implementing those individual functions?
Actually it might be easier to use some open source embedded code.
For completeness sake, I'd write the snippet above almost identically:
OK, now you've got me really confused. Is that Haskell code? I thought that Haskell couldn't do sequence except inside a monad. (Or is "do" a monad?)
But if that isn't a monad, then why did you write it that way? My original claim was that a monad wouldn't do much for me in my world, and if you wrote this without a monad, that kind of seems like you're agreeing with me.
You said that you'd gain composability from writing this as a monad. In this example, how would that work? What would it buy me that I couldn't write (as easily) using what to me is the normal way?
It would most likely be in the IO monad since IO would be happening.
As for whether monads would help your code (and I still think they would) I'll need a larger example. In a small example abstraction and reuse aren't really apparent.
If you can provide a larger example, we can find out who's right ;)
Alternatively I'll try to find a larger example if you can't or don't want to.
Well, I just made up this example, so feel free to embellish it...
But as you do, remember the question. We're in an embedded system, with lots of situations where sequence matters, and lots of stored state. The question is, what do monads buy me in that environment?
Actually it might be easier to use some open source embedded code.
For completeness sake, I'd write the snippet above almost identically: