5 ms·
In the Haskell world, folks have solutions to both of these problems: The "large-object problem" can be tackled in a principled fashion using strict state thre
by bts 5y ago
In the Haskell world, folks have solutions to both of these problems:
The "large-object problem" can be tackled in a principled fashion using strict state threads (aka the ST monad: https://wiki.haskell.org/Monad/ST https://wiki.haskell.org/Monad/ST) or using vanilla mutable (IORef) references.
The "parent-child problem" is well-addressed by lenses, also known as functional references. They are basically composable getters and setters that allow you to read or update deep into nested structures.
- marcosdumay 5y agoYou mean, Haskell developers ditch the functional idiom and use a more imperative one when they need it for performance? And yes, they do, and it works nicely. But it's not solving any problem with the functional paradigm. Anyway, none of them is a problem with the semantics of FP. They are a problem of insufficient optimization. So they will probably get solved at some point.
- travisathougies 5y agoST is not 'imperative'. The monadic interface can look imperative sure, but then you can also use Applicative and friends and that's back to being functional. Of course, I prefer to think of what you call 'imperative' programming as function composition where >>= is the reverse of the 'normal' composition operator. Indeed, sequential imperative commands and function composition are isomorphic.
- marcosdumay 5y agoHum... You declare an state and go modifying it with an action after another. Looks quite imperative to me. The fact that it returns an interpreter instead of values is meaningless if it doesn't change the way you think about the program. If you personally prefers to read it as the declaration of a program that given an state modifies it step by step, you can claim it's functional. But you are alone on that, the language even has specialized syntax to push people into reading the former, and anything minimally complex all but requires it.
- TuringTest 5y agotravisathougies is not alone on that. Every one of us functional programmers worth their salt will consider a sequence of transformations from one state to the next as a functional program, as long as there are no side effects outside the current function that may transform state in ways that aren't declared in the types of the input and return values (which would break the referential transparency). Functional Reactive programming (i.e. combining functions over streams of mutating objects) is essentially that, and it's a pure functional paradigm, quite popular in front-end web development (and I hear it's even creeping its way into the back-end).
- deleted 5y ago[deleted]
- mrkeen 5y agoThe benefit is same-input -> same-output.
- marcosdumay 5y agoOk, let's get specific. Here is an STM function: orElse :: STM a -> STM a -> STM a It returns the first argument if there isn't any synchronicity problem, or the second if some other execution line conflicts with the first. What exactly do you mean by "same input -> same output" and how exactly does a programmer thinks about that function on this way when composing it into an STM interpreter?
- mrkeen 5y agoI was referring to the ST monad which bts and travisathougies were talking about, not STM. I mean that when you run ST code twice with the same input, you will get the same output. E.g., if I write (runST f) + (runST f), that's the same as 2 * (runST f), etc. As for thinking, it means I don't use step-through debuggers ever, because I don't need the whole program to be in a certain state to watch what happens. I just grab the function, grab the input, and run it in isolation.
- blablablerg 5y agoYep it it is called declarative.
- SinParadise 5y agoI don't fully understand how parent-child problem is addressed by lenses. How does lens helps to address the problem that a reference update is akin to changes an external state? My understanding is that lens helps to address the large-object problem.