Are there monads that can be used like an automaton?

Question

I'm writing a stream transformer from some Input data type to an Output data type. Input is made by the user, so there is some time between the events. Because each input requires some resource loading, I'd like to "look into the future", i.e. send all possible inputs to the main computation and preload resources based on the results.

Currently, there is always exactly one output after each input but it might eventually become interesting to change this.

I succeeded to implement that with the Automaton transformer by Ross Paterson. I'm not sure my solution is optimal.

• Are there nice examples how to do this? Perhaps even with test code?
• Can it be achieved with a monad as well? (Examples?, Explanation why it's impossible?)

Edit: After the call for more specifics, I added code here. Now I'm removing it (it was not understandable) and add some other explanation. My question is answered thaugh.

My intention was to have the main event loop stop after each user input that has been fed to the arrow/stream transformer/whatever. Then it would store the current automaton state and send all possible inputs (fake events) one by one to the automaton and see what resources must be loaded, to cache them. After the next real event, it would use the cache for better responsiveness. The main computation should not be influenced by this.

Lamanna

not qualified to answer, but iteratees might be useful to you. See this library: hackage.haskell.org/package/enumerator ... but arrows would seem a good abstraction. I'll bet more specifics would help people answer. – Viviennevivify

Answer 1

All the use cases you mentioned are covered by the Netwire library. It provides a generalization of Ross' automaton arrow to a family of wire arrows. I haven't finished the wiki page yet, but it should give you enough to start.

Combining this with Kleisli (LogicT m) for some monad m you get nondeterministic wires.

And as an additional note: What you want is not a monad.

Chetchetah

Hallo Ertes! Can you explain why this is not a monad? – Lamanna

@Duschvorhang: arrows are a generalization of monads. See Haskell wiki > arrow – Urbai

@Duschvorhang: you can see a similar limitation in the parser example of §3.0 of John Hughes' Generalizing Monads to Arrows along with a careful explanation of how arrows provide the needed expressiveness. It's a nice read, besides. – Abdella

I started reading the paper by Hughes. I liked the arrow based interpreter a lot. I decided now to have a look at reactive-banana and try to learn from it's concepts. – Lamanna