Comments on: Free Monads for Less (Part 3 of 3): Yielding IO

By: reading Life coaching

reading Life coaching — Tue, 27 Sep 2022 22:29:12 +0000

reading Life coaching…

The Comonad.Reader » Free Monads for Less (Part 3 of 3): Yielding IO…

By: Edward Kmett

Edward Kmett — Sun, 07 Oct 2012 03:38:40 +0000

The irony with that is that it is particularly easy to add cases to a ‘Free’/a la carte monad in scala. Just don’t seal the class. ;)

To mitigate the boilerplate in Haskell at least, the typeclasses for config, db connection, etc. can be autogenerated by something like makeClassy from my lens package.

By: Richard Wallace

Richard Wallace — Sat, 06 Oct 2012 23:44:04 +0000

Ok, I understand the cost of tupling up more and more and that being undesirable. Also, you’re right that adding new constructors breaks the whole “a la Carte” notion.

I’m just looking for alternatives to the typical way of building FP apps of using a monad transformer stack with ReaderT and StateT and type-classes for all the data you want to inject (config, db connections, etc.). I was looking at the a la Carte approach as a way of doing that. Although, to be fair my distaste for this approach comes from a Scala app where it became a PITA to manage everything and if it had been written in Haskell the experience might have been different.

By: Edward Kmett

Edward Kmett — Fri, 07 Sep 2012 13:53:58 +0000

The difference is in order to support new operations with the usual free monad/a la carte approach you need to define a new data type or a new constructor, or tuple up more and more stuff and pay a higher and higher cost when accessing the next constructor.

We use this in a language we have here at S&P Capital IQ called Ermine as our only FFI mechanism. It isn’t something you could bolt into, say, GHC without changing out pretty much everything in the language, but in a new Haskell implementation, it has the benefit that you don’t need to deal with magic RealWorld tokens and then restrict transformations that may attempt to commute past them.

This enables you to transform the language more easily, in exchange, we denote operations with this separate FFI type, rather than primops, and view the runtime system as an external agent driving an asymmetric coroutine.

By: Richard Wallace

Richard Wallace — Fri, 07 Sep 2012 06:24:32 +0000

I’m not clear on what you mean by the set of FFI operations being closed with the “Data Types a la Carte” approach. It seems to me the point of that approach is to not limit operations. You just define new operations and interpreters for those operations.

I’m also not clear on how the proposed FFI type you’ve presented here works. How is it not limited? How would you define such a thing in Haskell? (Very curious about this approach because right now I’m planning on using the approach from “Data Types a la Carte”, but am always interested in learning about/using something better.)

By: Edward Kmett

Edward Kmett — Sat, 25 Jun 2011 18:24:07 +0000

@Chris: Nice!

By: Chris Kuklewicz

Chris Kuklewicz — Sat, 25 Jun 2011 14:13:18 +0000

After being clumsy for a while, I reached the end. Great post.

Reordering some arguments in IO to

(forall i o. (i -> r) -> FFI o i -> o -> r)

gives the more concise

unsafePerformIO (IO m) = m id fmap

which for simple FFI functions is

unsafePerformIO (IO m) = m id (.)

By: Edward Kmett

Edward Kmett — Sat, 25 Jun 2011 05:31:35 +0000

@Wren: parallelism works fine and was a large portion of the motivation for this approach. A program exists in a quiescent state. From the outside (a thread), I can ask a term to evaluate itself apply itself to an argument, and do case analysis upon the result. We apply that to main and keep pumping. Any of those operations can be performed in parallel; the answers to them are all referentially transparent! Hence we can have as many threads running as we want demanding those answers. We aren’t passing a world. The evaluator just responds transparently to demands from the RTS, potentially many such demands simultaneously.

By: wren ng thornton

wren ng thornton — Sat, 25 Jun 2011 04:36:35 +0000

Your language’s IO type is extremely reminiscent of the old pre-monad Haskell days of main :: [Response]->[Request]. Except that with the coroutine structure you ensure that requests and responses can’t get out of sync. That’s quite elegant. Much nicer than the RealWorld baton in a lot of ways.

Have you considered how parallelism plays into this model of I/O?

By: Max Bolingbroke

Max Bolingbroke — Fri, 24 Jun 2011 15:07:07 +0000

Unspeakably awesome series of posts: the idea density is so high :-). This has answered many questions for me, but raised many more that I now need to think about..