I can’t see why do you think that because of that kind of behavior that function is not pure (not even sure if that’s what you think too). I mean, the pipe operatore (|>) does get the left argument and send as the first parameter on the right function, so calling put_flash right in the beggining and calling in the end will call it with 2 different params, since in the latter put_session and redirect would return a new, altered, Plug.Conn.
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 completedconn 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, I still cannot see the functions there interacting with the HOW in any other way than actually receiving the params, and if that is what you mean by interacting with the HOW, well it must be really tedious to do anything in Haskell. But well, I don’t know much of it, so maybe I should invest a bit on learning it before asking those questions.
Yeah, I know about that, I was just really not getting the specific case there. I mean, I know BIFs, NIFs and processes can introduce side effects, but how put_session and redirect do that? This specific part of the code in isolation is pure as far as I can tell: they receive the params, and return the result, if the same params were given again and again to the same function, they would still get the same result over and over. Where is the side effect? Where the HOW gets in the game for that case?
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.
Right, in that case I agree, but the default is the cookie, and in that case the side effect is pushed to the edge of the system, when the response is sent.
Alright, true, yeah, there are side effects, was assuming that function worked on a different way (by doing something like leaving the response to be sent in the end of the plug pipeline). You are totally right, sorry for all the confusion, if the response was not sent on the redirect, there would actually be no reason to block people from setting the flash after calling it. Thanks for all the talk and sorry to take your time to explain that while I could figure it out by myself just digging a little on Plug’s and Phoenix’s code.
Think of the BEAM as a big Algebraic Effect engine in Haskell. The only ‘mutation’ goes through algebraic effects that the BEAM calls message passing. Everything within a process is entirely immutable, including the message passing, but it’s the ‘effect’ of passing messages between processes that causes the mutation in the overall world. The BEAM is pretty easy to reason about as a haskeller when thought of like that (because that’s what it really is).
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!
I actually thought the same as you, looks like we both were fooled here. Anyway, nothing like learning it the hard way: with some unexpected result, that way you remember it better.
