Timeline for Can functional programming used for solving problems which require randomness?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 10, 2021 at 10:46 | comment | added | wensveen | Nice analysis. I think it's worth emphasizing that by "simply" allowing I/O in languages like Scala, etc. one does break the idempotence aspect of FP, which was part of the question. It's possible to stay purely functional by using monads, as @JörgWMittag stated. That way the function is still idempotent but the randomness is represented in the result. It's like collapsing the wave function of a quantum system when you measure it, or something like that. :) | |
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot |
Commonmark migration
|
|
| Jan 4, 2018 at 17:31 | comment | added | Steve | @JörgWMittag, it depends what you mean by "being functional". If it means "employing a language described as functional", yes functional languages have I/O - but that is because those languages actually have non-functional features which allow code to be implemented imperatively, not because I/O is actually being implemented as a "function" (in the theoretical sense, rather than in the sense of a language construct or syntax). And the use of the imperative code causes the loss of the guarantees and the potentials that exist for the evaluation of functions. | |
| Jan 4, 2018 at 17:07 | comment | added | Jörg W Mittag | @Steve: There are plenty of ways of modeling I/O without deviating from being functional. Linear types, effect types, world types, effect systems, I/O monads, are but a few. Haskell alone tried out two other approaches (continuations and lazy streams) before settling on the I/O monad. | |
| Jan 4, 2018 at 8:03 | comment | added | Steve | I agree with the tenor of your analysis here about any PNRG that is implemented purely in terms of its inputs (and does not reference things like the system clock or any other environmental variable), but I would still make it clear that I/O is something that fundamentally breaks the functional-ness of the program and the guarantees that come with following a functional coding pattern, and puts the onus back on the programmer to manage all the potential difficulties of mutable state. "Functional" languages "model I/O just fine" simply by deviating from being functional, and that's a key point. | |
| Jan 4, 2018 at 3:16 | comment | added | Daniel T. | This is a good answer except to add that any PRNG generates a (potentially) infinite array of numbers from a given seed. That array is generated without any side effects. That said, it would have been nice to show some Haskell/Clojure code that actually does it. | |
| Jan 3, 2018 at 23:12 | history | answered | Jörg W Mittag | CC BY-SA 3.0 |