Interesting. You might want to take a look at the Eff library for implementing pure algebraic effects in F#. The effect handlers are a bit hairy to write, but the effectful code itself is quite elegant. Example:
// state effect examplelettest()=eff{let!x=get()do!put(x+1)let!y=get()do!put(y+y)return!get()}
I have seen various F# Computation Expressions out there for side effects. Practically speaking, workflows in Eff are harder to test than what I present here. (This will be true in general for monadic control flow.) To test decision logic in an Eff CE, you would have to implement mock effects. Which will lead you to write some non-trivial testing instrumentation. With what I demo above, you can test the logic directly without mocking effect implementations. Just data in and asserting that data out matches expected values. Also the effect implementations are comparatively easier to write, and this matters for maintainability too.
Side note: I've always felt that CEs and do-notation-type things are missing the point a bit. They are emulating an imperative style within a functional language. This can be very convenient at times, like with list expressions and conditional yields. But in most cases I had rather write code in a functional style.
Apologies, as I am a compulsive editor. This comment has changed drastically since first submission.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Interesting. You might want to take a look at the Eff library for implementing pure algebraic effects in F#. The effect handlers are a bit hairy to write, but the effectful code itself is quite elegant. Example:
Thanks for the suggestion!
I have seen various F# Computation Expressions out there for side effects. Practically speaking, workflows in Eff are harder to test than what I present here. (This will be true in general for monadic control flow.) To test decision logic in an Eff CE, you would have to implement mock effects. Which will lead you to write some non-trivial testing instrumentation. With what I demo above, you can test the logic directly without mocking effect implementations. Just data in and asserting that data out matches expected values. Also the effect implementations are comparatively easier to write, and this matters for maintainability too.
Side note: I've always felt that CEs and do-notation-type things are missing the point a bit. They are emulating an imperative style within a functional language. This can be very convenient at times, like with list expressions and conditional yields. But in most cases I had rather write code in a functional style.
Apologies, as I am a compulsive editor. This comment has changed drastically since first submission.