Over the xmas week holidays, I got to thinking about Subtext again. Since my conversation with the author had dropped off at the point where he said he's skeptical about getting subtext to work with normal programming languages as they're not functional and he doesnt want to bridge that gap, I set about thinking what would it take to bridge that gap.
And this led me to reading up on a couple of functional programming languages, and of course to Haskell. The thing that caught my attention was Monads, and the assertion that Monads was Haskell's answer to imperative programming - how it allows you to keep things pure and functional, and yet provide the "do this first, then this other thing" style, side effects and all.
This was, of course, exactly the opposite of converting imperative code to functional, but I thought the insight might be helpful.
Two days of confusion and a screaming wife later, I realized there's a reason monads have so many tutorials - they're pretty confusing concepts to start with. I'm still on shaky ground with them, especially having not passed that rite of passage of writing one all by myself, but the a-ha moment came from a post by Oliver Steele about how a monad is a rule that defines how to get from one statement in a program to the next, and further from this comment that even in lazy pure functional languages, f(g(h x) implies a sequence in with h is evaluated before g and g before f.
IMO, a tutorial is required that actually maps a monad's working to that of a von-neumann machine. Then, maybe, we imperative programmers will get it :)
Where does this leave subtext and my original thread of thought? I'm not sure. Would a conversion like this work?
Imperative code --> Monad equivalent --> functional code
How would the first conversion even happen? Need to think about this.
No comments:
Post a Comment