Thursday, July 8, 2010

On Compositionality.... and State

I am thinking on how to rewrite code, maybe not all but some of it. Thing is, in a functional language you can write code in combinatorial style, the best example of that being parser combinators, followed by monads and point-free style. I originally intended my language to be able to exploit that to the fullest. I.e., types help, and hand you, good guarantees to get your combinator libraries right, and the syntax (blocks for abstractions) help you define them.

I went in another direction at some point. Mostly, because I just found it easier to patch up some functional code.

Parser combinators are the best example of a good combinator library. A good collection of them does two 'things' at the same time: They pass on some internal state from combinator to combinator, the tokens processed. And, they pass on and combine return values; sometimes, with some extra arguments, they also take some input which may be threaded too.

Monads do exactly the same thing, but in some sense always in the same fashion. They just allow you to write a sequence of instructions with respect to a state, since the combining operators are restricted to return and bind. The question is: Is that really the kind of composition you are after?

Point-free style, as it stands, is not that much associated with combinatorial thinking. It is more a manner of using higher-order functions to program with the least amount of variables.

If you follow the combinatorial style, then the question is: How would you write combinators for document generation, code generation, dealing with game states and events, etc? And, second, can it perform? Now I think you can make it perform by just making the right abstractions and making the application, or composition, of combinators as efficient as possible. But how to get it right in the first place, is just a puzzle for me at the moment.

So, this is what I am after: Reduce everything to composition of code.

No comments:

Post a Comment