Refactors

[Anton-Latukha]

Reducing some current YAGNIs.

Starting reducing some superfluous things in the code (#879)

• Result type is really an euphemism to Either. Left Right is on the instinctive understanding for Hakellers, and using it enables further readability and plasticity to the code.
  Currently made Result, what it is - an euphemism to Either. Probably we may even just remove the custom type without any detriment, it probably would just make code even easier to read, since the Either semantics already fully embody what Result is, and the habitat of the function that brings Either shows where it came from. Outside of the module that exposes the data type Result is literally does not appear not once in type signatures anywhere over the project.

• forceEff changed a little, no reason to lock and then do preparation actions that do not required locking the whole process. So now doing preparing first and then locking right when it is needed.

• Please note that force{,Eff} implementations internally are now the same.

• queryM became non-locking, since read from static structures in a static language does not require locking operations.

---

Update:

• notice the implementation transformation for further - now it really shows the nature that all there was - it really simply defers the thunk. The question here is: since locking was not implemented for it, does atomicModifyVar needs thunk locking, or its atomicity allows this. But anyway, further family of functions used just 1-nce in a inform type cass instance that is not used at all.

• we arrived at that force{,Eff} are exactly 1 function, they are united currently under forceMain, the future (a cascade other MonadThunk instances above, for example, and future in general) would show does class MonadThunk needs forceEff, or forceEff is just force.

[Anton-Latukha]

I have an idea.

[Anton-Latukha]

Well.

Wanted to do something like:

Which would allow force = operateOnThunk . queryM, and implement locking as force = (withLock operateOnThunk) . queryM

But readVar ref requires MonadTrans.

-- (roughly)
  -- | Non-blocking query
  queryM :: NThunkF m v -> ExceptT (m v) (IdentityT) v
  queryM (Thunk _ _ ref) =
    do
      (\case
        Computed v -> lift $ pure v
        Deferred a -> throwE a
        ) =<< readVar ref

So far not married the types.

And because of MonadTrans requirement, the result would be hardly faster or better than the current code.

I am still uncomfortable with MonadTrans, though I can construct and operate on them slowly, but the added additional hassle, code noisiness & complexity, etc. they do not smile to me. So I'm being lazy with remembering them keep forgetting them and as lazy re-learning them or touch them.

I know that what uses State monad with enough (sometimes big) persistence - that the data processing code can be written properly elegantly without it, but short-circuiting the I to O response to help debug the process may take some time.

There is a continuation-passing style.

I just do not love MonadTrans for so many reasons, being so very lazy with it.

[Anton-Latukha]

In fact, talking about the continuation-passing style, instances I was refactoring were created with it.

So after creation, they were needed to be refactored inside-out to achive optimization.