Experimental effects support
Getting out of an effect system once you've gotten into one
Effect systems are being actively explored as ways to structure Haskell programs in the way that numerous competing efforts were exploring the streaming I/O space eight to ten years ago. We have found ourselves in a situation where we want to use Program τ as the base monad from within a codebase that has been heavily encumbered with the effect system from the effectful package, so have introduced a new core-effect-effectful package which provides experimental support for this.
We're hopeful that this new paradigm will mature and that the community will converge on a particular approach to effects that can be standardized and made robust. In the meantime, we're frankly not convinced that attempts to replace mtl style separation of concerns are well founded because building your application as stacks of monad transformers, though widely used, turns out not to have been a good idea in the first place. In terms of ergonomics, simplicity, and ease of use, stacks of effects don't appear much better than monad transformers, but we look forward to continued progress by the many teams working on this.
In the meantime, having a top-level application state that contains the settings and resources needed to perform various actions in the external world appears more than sufficient for many applications, and so we continue to encourage interoperabiltiy via the Program τ monad provided by this library. To that end, this new package introduces a new ProgramE τ effect that allows lifting and unlifting from effectful's Eff es to core-program's Program τ, so that applications needing to use a complicated effect system can still get access top-level program utilities such as concurrency, logging, and telemetry.
Documentation for Core.Effect.Effectful is on Hackage.
Bug fixes and general improvements
Add a check at startup to ensure that the program was linked against the threaded runtime (using the -threaded GHC option). It turned out that sending telemetry was failing (probably due to the network library being FFI, of course) when the program was built with the old single-threaded runtime which unfortunately is the default of you don't tell GHC to do the right thing.
This isn't really a unbeliever thing, because really it's a Haskell thing. The notion that the original single-threaded I/O manager is a good idea because it's the stable original established choice is at least a decade out of date. The default really should be -threaded so you get the parallel garbage collector, parallelism for your concurrent code, and actual benefit from the multiple-cores on any modern system. Our position is that the library should just work at all times, so we now check for it having been built with the multi-threaded runtime.
Finally, a really nice improvement to the documentation for the Honeycomb exporter in Core.Telemetry.Honeycomb is also on Hackage.
Full Changelog: core-program-0.6.2.1...core-program-0.6.2.2
