Re:Resolving the Time Paradox Implied by Functional Programs
by Smaug123 on Sunday December 27, 2020 @06:44PM
(#25555215)
Even "fold : (state -> a -> state) -> state -> a list -> state" implies this resolution. The function is pure, but in some sense it assigns a "program state" to every element of the list. Having created a time evolution of the computation, we then essentially throw away all but the last. For optimisation reasons, of course, we don't actually generate the entire intermediate list of program states.
[ Parent
| on HN ]
Re:Resolving the Time Paradox Implied by Functional Programs
by lisper on Sunday December 27, 2020 @09:01PM
(#25556037)
The fundamental problem is the opposite one: it's the world that throws away intermediate states, and that happens whether you want it to or not. Unfortunately for FP afficionados, physical reality runs with autocommit set to True.
Re:Resolving the Time Paradox Implied by Functional Programs
by lmm on Sunday December 27, 2020 @10:20PM
(#25556398)
> it's the world that throws away intermediate states, and that happens whether you want it to or not. Unfortunately for FP afficionados, physical reality runs with autocommit set to True.
This fact is unfortunate for OO aficionados who try to build programs by modelling the real world, because it leads them to build programs with the same problem. Whereas FP aficionados realise that even though there's no "undo" in the real world, we can enable it in our programs.
Re:Resolving the Time Paradox Implied by Functional Programs
by chrisweekly on Sunday December 27, 2020 @10:31PM
(#25556441)
touché!
Re:Resolving the Time Paradox Implied by Functional Programs
by notduncansmith on Monday December 28, 2020 @12:08AM
(#25556852)
> physical reality runs with autocommit set to True
Only from the inside ;)