Haskell (and Elm) is singleminded in its pursuit of purity. Functions like put_session and redirect could exist but rather than directly (and rather imperatively) interacting with the HOW (horrible outside world) those functions would simply register the intent to interact with the HOW somewhere inside the conn. It’s only when the completed conn is handed over to the runtime that those interactions with the HOW happen under the runtime’s full control.

The Clojure community often talks about how immutability helps them to push side effects to the edge of the system. This effect is captured architecturally in the Ports and Adapters architecture (see Functional architecture is Ports and Adapters by Mark Seemann).

The way put_session and redirect in Phoenix work aren’t consistent with a functional core imperative shell kind of approach and could be surprising to somebody coming from a background of functional design which practices a higher level of purity.

well it must be really tedious to do anything in Haskell.

It would be tedious to do something like that in Erlang/Elixir.

Given how Haskell embraces monads (less intrusively in Elm) it is actually relatively simple but it does require a significant shift in thinking. “Regular” programming is like flying the plane yourself - programming in Haskell is more like filing a flight plan and having the autopilot do all the dirty work.

Where is the side effect? Where the HOW gets in the game for that case?

• put_session stores information in session storage which depending on configuration is either Plug.Session.ETS or Plug.Session.COOKIE. Putting a value into an ETS table is interacting with an external mutable entity and therefore classifies as a side effect.
• redirect sends the response. To do that it has to interact with the web server which is part of the HOW. And sending the response is a side effect.

Update: looking at the code put_session simply updates the conn struct - so the interaction with the session store is actually happening at the edges (via the plug instantiation).

It’s the call to the session plug that fetches the state from the session store and places it in the conn. At the same time before_send is registered to save the session state back to the store just before the response is sent.

https://github.com/elixir-plug/plug/blob/v1.8.3/lib/plug/session.ex#L60-L104

I was about to write all these to you, but peerreynders wrote it much better than I could. Let me explain why I was confused. The main issue here is that most of the functions take the Plug.Conn struct as an input and generates a new (slightly different) version of it as an output; there was no side-effect, not even in the put_session function. However, the redirect function was different. It had side effects - that is, sending the response to the user through the server. I was too blind to side-effects, assumed that a functional language would at least try to avoid it until the very edge. I thought the side-effects would be declared through the Plug.Conn struct, but only invoked after it is returned.

Should have checked the docs before I started this thread, but it’s nice to see people discuss about this and explain the situation to me. Really liked Elixir and Phoenix’s community, you guys are great!