@Wes Thanks for asking here before asking on the site. Your question is generally on topic on Software Engineering. However, it's not a very good fit right now:

– You ask many broad sub-questions. (How would one go about using shared state between two or more consumers without using variables? Is there a standard pattern for this type of work? If this is the case how can the mutable state be minimised? What patterns do people use for scala in web applications with internal state?)

– You reference many external resources. It is great that you did your research first and show it! But please make sure that the question is self-contained. We should be able to answer it without having to read through all of them.

Btw, one of the comments already has the answer I would post: “Functional programming is not about eliminating state alltogether […]. The idea is just that the interaction with the state and all other side-effects is pushed to the boundary of the system as much as possible. In Haskell, it's pushed completely to the runtime system.” (source)

@amon Thank you. I think the sub questions are all kind of paraphrasing each other, but I get the point. If the question was what is the best way to have shared state between threads while adhearing to the principals of functional programming in scala, Would that be more directed?

its certainly a mouthful.

“Best practice” questions are not very welcome because they tend to be fairly opinionated. “How can I design this?” questions motivated by a real problem are better. But it seems you are asking about general concepts, which is also OK.

And with regards to content, your question has the premise that “shared state” and “having state” is a thing, especially in FP. Because this premise is partially wrong, this question appears difficult and confusing.

So a better question might be “Problems like {some example} assume some shared state. But how can that be modelled with functional programming?” But that's covered by the comment I quoted above: the state is pushed to the system boundary. The state is in the environment, not in the program's control flow or data model.

I'd also like to point out REST APIs in web programming. REST is about state transfer and not about sessions of shared state. Maybe looking in that direction will clear things up or help to formulate a clearer questions?

Oh, and FP covers a whole spectrum of approaches, from “imperative programming but with some closures” to “pure functions and immutable data only”. Scala is very chill about the paradigm you use. It's a perfectly fine programming language even if you only use it as a “better Java” and prefer the OOP parts.

thanks.

@amon Assuming its haskell you write and assuming it does http requests. How would I write a http application in haskell that has two endpoints. 1 which accepts a post (wrapped or otherwise) that contains a chunk of plain text, and a second endpoint that returned the count of all the words received or even the 10 most common words, without relying on an external data source.

If my assumption of having state is wrong. It may be just termonlogy. What I asked above is the crux of the matter. Running values.

I've never written a server in Haskell, so I guess the real answer would be “the State monad”. But for the purpose if this question, assume we don't have the standard library monads. Instead, let's first define our server main loop that receives responses:

def mainLoop(stateOfTheWorld) ={
   val (request, stateAfterReading= = readRequest(stateOfTheWorld)
   val response = someHandler(request)
   val stateAfterWriting = writeResponse(response);
   return main(stateAfterWriting);
}

(using scala-ish pseudocode)

in imperative programming languages including Scala, the state of the world is totally implicit. But we can choose to make it explicit where this is suitable.

For example, the handler function can return the handler for the next request:

def mainLoop(stateOfTheWorld, handler) ={
   val (request, stateAfterReading) = readRequest(stateOfTheWorld)
   val (response, nextHandler) = handler(request)
   val stateAfterWriting = writeResponse(response);
   return mainLoop(stateAfterWriting, nextHandler);
}

Each handler may be totally immutable, but because we can return a different handler we can persist data from one request to the next

So for example just to count the number of requests:

def countingHandler(request, count) = ("", { r => countingHandler(r, count + 1) })
mainLoop(startingState, r => countingHandler(r, 0))

In practice, not all mutability is evil. As long as each function behaves like a pure function, it's totally fine to use mutable variables internally. E.g. instead of defining that recursive main loop, I would have no problems with a literal loop that reassigns a nextHandler variable.

But this general pattern – receiving a state and producing a new state, whether that's an IO monad or a request count – allows us to implement useful behaviour with pure or mostly-pure functions.

Thanks I'm digesting this.

I can't star it as one chunk :'(