Comments (7)
Sorry, I probably haven't been clear in what I think of the overall change: I don't mind, but we need
to get a consistent picture of how all the classes work together.
An alternative would be to expose weaker classes as an addition to what we have: e.g. a ConcurrentState
and MutableAsk
from cats-mtl.
whereas it seems (superficially) appealing to have that as a policy decision the integrator can vary later.
Yeah, but the sort of code you can write sanely hugely depends on that. For example, having modify
be a non-primitive get andThen set
is only valid in the non-concurrent scenario.
Whether a piece of code needs ReadWrite or merely ReadOnly access to some state.
Yeah, fwiw I don't think this request is unreasonable, it's just not what ApplicativeAsk
has been intended for traditionally
from cats-mtl.
This kind of stalled with concerns around concurrent state #120, but I dont think this issue need be entangled with that.
Having considered both threads, Im convinced is reasonable and safe to opt-in to viewing State
/MonadState
as Reader
.
The thing that's not reasonable is to use State
/MonadState
with Ref
because it breaks the state laws around get
ting back what you set
due to potential concurrent modification. A weaker concurrent state abstraction is needed.
Specifically, I propose import cats-mtl.ApplicativeAsk.deriveFromState
to opt-in to the conversion.
from cats-mtl.
So it turns out this was removed by @LukaJCB , see #31
What about a happy medium to allow opt-in through an optional extra import, rather than the always-on that was there previously? perhaps something likeimport cats-mtl.ApplicativeAsk.deriveFromState[S]
enables the conversion for a type S
?
Also discovered that way back @edmundnoble wrote a law that would preclude it, but this law was later removed and now weakened to something that does permit State as Ask.
For myself, I find it useful to view State as Ask, to signal in the type-signature that some code cannot update the current state. I'm not sure what the arguments against are based on, beyond the tradition that "readers read from an immutable environment". State is immutable in that sense as well, I'll remind viewers.
from cats-mtl.
, beyond the tradition that "readers read from an immutable environment". State is immutable in that sense as well, I'll remind viewers.
I don't think I agree with this sentence (although I haven't made up my mind with respect to the entire argument).
Readers reading from an immutable environment boils down to expecting:
(ask, ask).tupled <-> ask.map(x => (x,x))
i.e. asking twice gives you the same result. MonadState
is consistent with this traditionally, because traditionally MonadState
has been exclusively used with sequential state a la StateT
, so unless you are explicitly putting a state operation in between ask
s, you have no problems.
Increasingly often though, MonadState
is used to represent concurrent state (e.g. by backing it with a Ref
), and that would break the assumption
So I feel like this issue is related to #120
Where basically we need to decide what we want MonadState
to be.
Also, I think things get more interesting once you consider local
as well, which is literally about having local only mutation, which can also implemented with StateT
but definitely breaks with concurrent state
from cats-mtl.
I admit my previous experiences have used sequential, deterministic State and I hadn't considered the concurrent case.
Seems like there are two separable dimensions here:
-
Whether a piece of code needs ReadWrite or merely ReadOnly access to some state. That distinction seems to me important to encode into the type signature, and is the goal Im trying to hit by raising this issue. I'm not sure if/how I can achieve that with current Cats MTL typeclasses.
-
Whether the system state is sequential&deterministic or concurrent&non-deterministic.
A question: from library user's POV, does it help or hinder them by requiring different type-classes (TCs) to read/write from concurrent vs sequential state? Different TCs imply that the choice of state representations (ie concurrent vs sequential) is baked into the code when it's written, whereas it seems (superficially) appealing to have that as a policy decision the integrator can vary later.
from cats-mtl.
(at the risk of restating a pre-existing discussion) So are there four concepts here that could potentially each be a typeclass?
AtomicAsk
: ReadOnly access to non-deterministic state (borrowing @kubukoz's naming here ). Weaker laws
AtomicState
: ReadWrite access to non-deterministic state. Weaker laws
ApplicativeAsk
: ReadOnly access to deterministic/immutable state/environment.
MonadState
: ReadWrite access to deterministic sequential state
If the latter two are "sub-types" of, or imply, the former two, then writing a program in terms of the looser constraints (ie AtomicAsk
, AtomicState
) might retain the ability to vary the state representation at "integration-time" ie after code has been written, which seems nice-to-have .
from cats-mtl.
Related Issues (20)
- Write a ton of documentation HOT 4
- Hand-write (or scalafix) syntax stuff
- Add a cats-mtl-free submodule
- Inductive instances over ContT HOT 4
- Documentation links return 404 HOT 1
- Add low-priority materializations for Handle in terms of ApplicativeError HOT 3
- Inconsistent use of def vs val in embedded typeclass
- New typeclass to run reader-like effects HOT 1
- Can't migrate from v0.7: StateT[EitherT, ...], ...] vs. EitherT[StateT, ...], ...] HOT 1
- Release for 3.0.0-RC2 HOT 1
- Release for Scala 3 HOT 3
- CI publishing failed HOT 1
- Website publish is failing in CI
- Release v1.3.0
- Scaladoc link is invalid now HOT 3
- handle error with partial function
- Cat
- Rebranding Cats MTL to emphasize the Capabilities, not the Monad Transformers HOT 11
- Different Ask typeclass requirements in a same stack monad HOT 3
- Support Scala Native 0.5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cats-mtl.