That's one more point added to the discussion what's considered idiomatic and well-performing Swift code. It's sometimes easier to prevent redundant copies and allocations with inout and var and use for ... in instead of map and forEach, than to expect the compiler to always optimize everything to the same degree. With for inout bindings that will eliminate the remaining need for something like modifyEach. After that, the only remaining thing to cross off my personal wish list would be for ... in ... where expressions (not statements), which ideally give us an optimized replacement for map and filter.
i assume @tera was running benchmarks in release mode.
as @Nevin pointed out earlier, for ... in has its own problems with holding on to a reference to the base collection while the update is taking place. you can fall back to the explicit index-based iteration style to avoid that, but it’s a lot more awkward to write.
I can see how limited use of var along with inout can lead to a proper emulation of the State monad. I'll do some more consideration on the point of purity, I do have a small holdup that prependWorkersHomeStreet is technically returning (), while in the State monad in Haskell it'd be returning something like State User (), so it falls more in line with the technical definition of purity (as the total impact of the function call is the value it's returning). However I'll keep an open mind here because I get that the idea is that there's an "implicit State monad" being wired through the app by the language, so the "real" type of prependWorkersHomeStreet is supposed to be viewed in that context.
I do still have at least one practical hangup about the Swift solution here that would scare me away from using it while I am totally comfortable using the State monad in Haskell, that @Max_Desiatov mentioned:
The fact that this is unknown at compile time and can randomly blow up at runtime is uncomfortable, especially if I were to introduce these patterns in codebases with other people who are less familiar with Swift's rules here.
Scoping var incorrectly changes it from an emulation of the State monad to something so dangerous it literally just blows up the runtime.
Code like this is encouraged as a proper isomorphic transformation of pure, State-monadic code to idiomatic swift:
I don't like how easy it was to get from "perfect idiomatic Swift" to "blows up at runtime with no compile-time errors or warnings", from a seemingly innocent change to someone unfamiliar with the rules here.
As far as I can tell, this is the view on vars with regards to value types:
It's encouraged to use almost exclusively vars as fields for structs
It's horrific to use vars ever as static fields for structs (I don't even know if this is the position of the swift community, it seems like it would be)
It's fine to use vars as bindings in functions
None of this even touches on the nature of vars for reference types, which would probably universally be discouraged, but I'm not even sure. It strikes me as overly complicated, and I feel I have a high tolerance for these kinds of things. I think some of it is the mix of the keyword var being either strongly encouraged or strongly discouraged based on context. Once var starts proliferating through value types, someone writing code on a reference type without intricate knowledge of the language might think "ah vars aren't that bad" and then they'll start varing fields there too.
I like your example. Note that with the "equivalent" (well, not exactly equivalent) code there will be no blowup. Just the value of "me" would be written twice:
struct SomeFeature {
static var me = User(name: "Nevoic", age: 684)
static func perform() {
let a = birthday(me)
me = a.1
print(a.0)
let b = nameChange(me)
me = b.1
print(b.0)
print(me)
}
static func birthday(_ user: User) -> (String, User) {
me.age += 1 // oops!
return ("Happy birthday!", user)
}
static func nameChange(_ user: User) -> (String, User) {
var user = user
user.name = "Potato"
return ("Congratulations on the new name!", user)
}
}
Maybe that's repl.it thing? I tried the code in the "app" Xcode project (including with thread sanitiser and address sanitiser enabled, exclusivity memory access check = full) and can't see the trap.
In tera's version example, the inout parameters to birthday and nameChange were changed to regular value parameters, so the calls birthday(me) and nameChange(me) will pass a copy of me at the point of the call instead of attempting to make an overlapping write access. So there wouldn't be any exclusivity trap in that case.
The upcoming strict concurrency checking for global variables will hopefully help discourage wanton use of mutable global variables, since the safety implications of shared global state will be more in your face with strict concurrency checking enforced. I do think it would be nice to formalize a "pure" function annotation that prevents accessing shared mutable state and only allows immutable and/or local mutation operations.
I think you are completely off the mark here, on several points.
The function prependWorkersHomeStreet is pure in all senses. The distinction here is related to the fact that, due to some language-specific features, we can do 2 important things:
instead of writing free functions, for example in the form of (User) -> User, we can write methods on types, completely equivalent save for the fact that the input is implicitly self;
instead of writing methods that return a new value of Self type, we can write mutating methods, in which the new value is returned implicitly to the caller, that is forced to reassign it to the variable to which the original value was bound; this is still a bona fide new returned value, the only thing that changes is the underlying machinery to move values around.
In other words, when dealing with structs, (User) -> User is the same as (inout User) -> Void, the second being just a more convenient version.
Let me quote again the definition of side effect that you posted:
An effect-free mutating function only modifies variable values inside its local environment (self), and it "returns" the new value to the invoker, but in a different way than what is expressed by the signature (User) -> User... thus, again, (inout User) -> Void is just a different, more convenient way of expressing the fact that a new User is returned, powered by the Swift value semantics mechanics.
For the same reason, the function is also referentially transparent, the point being that the returned value is expressed differently, so the procedure to verify the referential transparency is different:
// with function call
var user = User(...)
print(user)
user.prependWorkersHomeStreet()
print(user)
// replacing the call with the returned value directly
var user = User(...)
print(user)
user = modifiedUser // this is the returned value, and must be reassigned to the user variable
print(user)
// both have the exact same effect
If we squint, we could consider a mutating function as producing an "effect" in the sense that it has the "effect" of requiring a var variable to be called, and it will implicitly reassign the variable after execution, but this is hardly a "side" effect, it's fully controlled, and it's comparable to, for example, retuning a Future from a pure function.
I think that's the core of the issue: the discussion that you started is very interesting and informative, but the missing piece here is that Swift value semantics (some aspects of which are unique to the language) make functional programming more convenient without the need to rewrite other, completely different languages, with different styles, in Swift.
My Swift code is, say, 90% purely functional, save for some carefully controlled conveniences, and almost all functions I write are pure, but instead of trying to write Haskell in Swift, like I used to do many years ago, I embraced the features of the language that actually help writing more functional code, and mutating and inout are among those features. In this process, I was also compelled to abandon the classic Optics encoding.
This has been the question I've had throughout this conversation where people have stated that:
(T) -> T
is isomorphic to
(inout T) -> Void
It seems (to me anyway) that the latter is an effect-ful function (mutation is the effect and shared mutable state such as is generated here creates a race condition if accessed from multiple threads). While the former func may or may not be effect-ful in Swift, we can for purposes of this conversation presume it to be pure.
So it doesn't seem like those two functions would meet any definition of an isomorphism that I'm familiar with because composing them together will not produce the original pure function - unless you insist on operating in a single threaded environment. If this is being referred to as an isomorphism under that assumption, I can understand it, but not in the multithreaded case. In that case, the former function would avoid the concurrency problem while the latter does not.
I think the compiler agrees with me that the latter function is effect-ful and produces race conditions because in @tera's implementation immediately above, it produces an error message precisely to prevent you from using the latter function without accounting for effects.
Could someone explain if I am right in understanding the isomorphism argument here?
Slava’s response regarding the use of the term “isomorphism” from another thread is highly relevant here as well. The claim is not that there is no way to observe the difference between the two functions within the language semantics, but rather that you can transform a (T) -> T into an (inout T) -> Void and vice versa in such a way that the composition of those transformations is the identity transformation.
I see that. My point is that you don't actually get back the identity function when you do the transformation (T) -> T => (inout T) -> Void => (T) -> T, what comes out the end is an effectful version of what went in.
inout parameters by themselves do not introduce any outward effects, nor does passing local state as an argument to an inout parameter. The side effects (if any) arise in the caller if it tries to pass an argument that is shared mutable state, such as a global/static variable or class property. Going from (T) -> T to (inout T) -> () and back doesn't require referencing any shared mutable state so doesn't incur any outwardly-observable effects.
The "outwardly-observable effects" part is the key. To elaborate on this point, if we had a hypothetical pure annotation for example, the most useful interpretation would be "this function has no side effects I can observe" and not "every primitive step in the function's implementation is itself referentially transparent".
Sorry, to clarify, I meant that they are completely equivalent if they are pure: if they're not pure (so, not relevant to this discussion) we can always come up with edge cases where they would work differently.
As I mentioned, there is one specific "effect" associated with a mutating or inout function, that is, assigning the new value back to the original variable: this is controlled (it's not "side") and the compiler provides some guarantees (and could probably provide more), but if the function is otherwise pure, this effect is not actually relevant.
So, for the vast majority of cases, the two forms are completely equivalent, that is for example, I can always replace all pure instances of (T) -> T with (inout T) -> Void and produce the exact same result (even non pure ones, if their side effect is not the specific one that would create problems).
They are methods in a mutable class, so I'd say no in general.
We don't need a formal definition of pure in order to write, use and structure most of our programs with pure functions, but I think it could help, I would likely use it often: the only issue I see is that some side effects don't matter that much (for example, logging), but they would renderer the function not pure, but maybe we could also introduce a contextual unpure keyword to mark unpure lines that are acceptable.
