Re:Safe dead code removal in a pure functional language
by Blikkentrekker on Thursday January 28, 2021 @04:08PM
(#25949228)
Only to return information about the effect's success, which would again make it easy to see that the function must have some effect, if all it returns be true or false or another trivial value that could be constructed from æther.
[ Parent
| on HN ]
Re:Safe dead code removal in a pure functional language
by tsimionescu on Friday January 29, 2021 @01:56AM
(#25954806)
I think a general case is concurrent mutation of a data structure. If you are adding some item to a list in parallel with others, you will usually need to return some token (e.g. index) that will allow your caller to retrieve that item later.
You MAY be able to get away with making this a pure function by returning a shallow copy, but I believe that depends on how central the sharing aspect is.
Re:Safe dead code removal in a pure functional language
by brundolf on Friday January 29, 2021 @12:31PM
(#25959894)
Yeah, so the problem here is that the value creation logic is non-deterministic; not only does it depend on hidden state, it doesn't even do so predictably because you don't know the order in which other threads might interplay. I established three categories of imperative-logic-return-values above:
> The return value is either going to pertain to the state before the side-effect, the state after the side-effect, or the side-effect itself. The first two could easily be broken out into pure functions. The third, again, mostly comes down to error reporting.
So this definitely falls into category three, which makes the coupling legitimate. It's possible I was wrong in my statement that that category "mostly comes down to error reporting"; it was just based on my own past experience.