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.
]]>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.
]]>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.
]]>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.)
]]>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 (.)
]]>Have you considered how parallelism plays into this model of I/O?
]]>