As others have stated, that's all done as libraries in Haskell in a variety of ways.
I'd be interested in knowing how the order of the combined effect types are resolved in Koka, though. For instance, in `<io, ndet>` the ndet effect will end up conducting a search. How do the (observable) io side effects get woven into that search? In particular, how does Koka know the proper ordering?
In Haskell, you'd be forced to eventually declare an order to your monad stack (although most functions can be agnostic to the particular choice). So in this instance, you would write `LogicT IO a` to indicate that the non-determinism gets resolved first while most functions would be of the form `(MonadIO m, MonadLogic m) => m a` where the parenthesized set of constraints is unordered.
Hm... if I understand correctly, the `ndet` effect isn't non-determinism in the sense of amb, but rather non-determinism in the sense or random. I.e., there is no search, it's just producing a random number.
Ah, sorry. The question still holds, though it's less obvious what it means with this effect stack. Perhaps a more obvious example would be failing, stateful computation written as follows as an order-free restricted type in Haskell
( MonadPlus , MonadState s ) => m a
Given some concrete choices of monads to witness those effects like MaybeT and StateT there are two "orders" we can stack them.
MaybeT (StateT s Identity) a
StateT s (MaybeT Identity) a
where Identity forms the "effect free" base of our stack. While functions which operate on types with the order-free signature work for each stack, ultimately the stacks represent different combined effects. In particular, the `StateT s (MaybeT Identity)` stack throws away state if the computation fails while `MaybeT (StateT s Identity)` does not.
run1 :: StateT s (MaybeT Identity) a
-> s -> Maybe (s, a)
-- failure captures the result state
run2 :: MaybeT (StateT s Identity) a
-> s -> (s, Maybe a)
-- result state always produced, failure captured
-- only in the result value
So, ultimately the semantics of your effect set depend upon the ordering of your effects. At least in Haskell. I'd be interested to see how Koka handles it.
If I understand Koka correctly, it's type system is purely descriptive, and has no effect on runtime. Having said that, Koka is a strict, eager language (at least currently, as it's compiled to JavaScript), so effects happen in the order that they appear in code. It doesn't support "handlers" like Haskell or Bauer & Pretnar's Eff.
Eagerness doesn't really matter for this purpose. It has more to do with "overriding" or priority of effects. I'll just look into it later. Thanks!
If it's anything like purescript's extensible records effect system then there are "handlers" which determine effect order/priority (see http://www.purescript.org/posts/Eff-Monad/)
I'd be interested in knowing how the order of the combined effect types are resolved in Koka, though. For instance, in `<io, ndet>` the ndet effect will end up conducting a search. How do the (observable) io side effects get woven into that search? In particular, how does Koka know the proper ordering?
In Haskell, you'd be forced to eventually declare an order to your monad stack (although most functions can be agnostic to the particular choice). So in this instance, you would write `LogicT IO a` to indicate that the non-determinism gets resolved first while most functions would be of the form `(MonadIO m, MonadLogic m) => m a` where the parenthesized set of constraints is unordered.