[garethrowlands]

Surely transactions are a pretty good example of where functional core / imperative shell is a good guide. You really don't want to be doing arbitrary side effects inside your transaction because those can't be backed out. Check out STM in Haskell for a good example.

[mrkeen]

> You really don't want

And that's what this thread is filled with, and that's what I'm pushing back against.

> the RAI pattern is nice

> indicate if you are in different sections is nice

Style doesn't matter, flavour doesn't matter, wants don't matter, code "quality" (whatever that means) doesn't matter, niceness doesn't matter.

A transaction can be rolled back. If it can't, it's not a transaction.

[taeric]

I'd go a little further, though? Transactions have to be able to fail at the very last step. That could just be the "commit" stage. Everything up to that point could have been perfectly fine, but at commit it fails. More, the time of execution of that commit could be fairly far removed from the time of starting the transaction.

To that end, any style that tries to move those two time periods closer together in code is almost doomed to have some either hard to reason about code, or some tough edge cases that are hard to specify.

(Granted, I'll note that most transactions that people are dealing with on a regular basis probably do open and close rather close to each other.)