Is the naming not final yet? I thought with the releass of the library all future changes would've to be backwards compatible

But I guess it has to be revised anyway when KEEP-87 is accepted (fingers crossed)

Arrow is in a 0.X series and we guarantee no backwards compat

we can rename

As for

runA

and `runS`: are they even really needed? It's easy enough to extract the state/value from the result tuple (maybe a Pair alias should be used here). In any case, I think the docs should be kept as simple and self explanatory as possible. The more specialized cases/best practices can be explained further down

They are not "needed" but they are there because they are also in other impls of the State monad and many of our users are FP devs coming from other langs such as Scala

We tend to provide familiar names to 2 audiences. OOP devs coming from Android, Java and Kotlin and FP devs coming from Scala, Haskell, Ocaml, and others.

but those methods could be maybe renamed or with aliases to

runState()

and

runValue()

IMO the best way would be to get rid of runA/runS and let run return a Pair alias with state/result instead of fst/snd. That is also in accordance to the functional paradigm of expressing your data in ADTs. After all, the resulf of the monadicc computation isnt just any Pair, it's a StateMonadResult where one component is explicitly the state and the other the value

that method is already there, but you are saying you want no aliases runA and runS in addition to run?

What if they were called

runState()

and

runValue()

?

To this day, my first guess at

snd

is always “sound”, never “second”.

@cedric one of the worst offenders in Haskell imo

Makes me want to hit my

fst

on the desk

To be clear, would this be acceptable naming wise to you guys?

fun run(): Tuple2<S, A>
fun runState(): S
fun runValue(): A

?

runState and runValue are definitely much better. But imo they are not needed when you can just write run().value or run().state. Also it makes the inner workings more obvious.

Do you "run the value"? Not really. You run the monadic computation and the result will be a state and a value. So State.run().value makes more sense to me

fair point, if you want to submit a PR we will get them changed.

I'll look into it tomorrow. I wanted to make some contributions to the docs anyway, but first I have to understand how everything works under the hood

I’m somewhat (ir)responsible for typeclass emulation and names etc

so I’ll be around to answer questions too 😄

Also State should really be named Stateful or StatefulComputation imo. But it's debatable how a name change here would hinder adoption considering all the existing blog posts on haskells State monad

It's not really stateful just a bunch of chained functions where any arbitrary state you seed into it is passed in args and returned back but it does not work with the world state. It's entirely stateless and immutable returning a new

State

value on each function such as

map

flatMap

etc.

yeah, I see how that could be misunderstood. Still State feels wrong to me. It's not really the State itself but a computation that works with a State. Maybe I can come up with a good name later

I think that is a popular name in OOP as well for things that are not the State. For example a

State Machine

is a well know pattern. For what is known chaning the data type and typeclasses names it's something most people are not a fun of https://github.com/Kotlin/KEEP/pull/87#issuecomment-333672535 specially when we are speaking about well known data types in many languages.

Monoid and Functor actually come from math though while State is purely a programming concept (probably originated in Haskell). Maybe it could be named StateMonad but that kinda sucks too. After all it's not just a monad

(Besides not even making it any more readable for someone who's not already familiar with the state monad. So not much is gained)

@Itua yes I've only heard ever the State data type be called

State

. We also have

MonadState

in the mtl module that is a typeclass that abstracts away from the data type since other datatypes could potentially implement the functions in State and provide an alternative implementation. Also State itself it's an alias to

typealias State<A> = StateT<IdHK, S, A>

Since the State itself is not that useful over Id but other more powerful and commonly used ones such as IO. In practices most people would end up using

StateT

unless they are using State for synchronous computations.