3 ms·
Explain why closures are allowed to mutate state in this “simple, well understood” framework.
by jtdev 5y ago
Explain why closures are allowed to mutate state in this “simple, well understood” framework.
- valenterry 5y agoThey are not allowed to. Why do you think they are?
- jtdev 5y agoFrom the Swift docs regarding closures (I would have used Haskell doc reference, but the Haskell docs are so esoteric and vague as to be nearly useless): “A closure can capture constants and variables from the surrounding context in which it’s defined. The closure can then refer to and modify the values of those constants and variables from within its body, even if the original scope that defined the constants and variables no longer exists.” https://docs.swift.org/swift-book/LanguageGuide/Closures.html https://docs.swift.org/swift-book/LanguageGuide/Closures.htm...
- valenterry 5y agoSwift is not a language that enforces code to be pure functional though.
- jtdev 5y agoFP = debating largely academic nuances that have almost zero material effect on software deliverables, purely for ego driven reasons.
- ebingdom 5y ago> From the Swift docs regarding closures What makes you think Swift only supports functional programming? > I would have used Haskell doc reference And if you would have, you would have disproved your own point. In Haskell, closures cannot mutate state, because mutable state is not part of the language semantics. It's modeled explicitly via monads.
- pflanze 5y agoWhether closures are or are not allowed to mutate state depends on the programming language (or the aim of the programmer, if the programming language doesn't force their way). Closures are a syntactical building block helping functional programming (building functions out of objects is just much more syntactical overhead), but whether a particular closure is a pure function or not is a separate concern. If the function is to be pure (hence satisfying the core of the "framework") then it would not be allowed to mutate state.