I didn't mean purity in the Haskell sense, but the more general technical sense the original message seemed to me to be reaching for. Purity in the Haskell sense is indeed a more limited question. But languages that are useful int he real world need to make tradeoffs, and even Haskell's version of purity includes such (IO is in many ways a wart, but there's going to be a wart *somewhere*).
Am 30.07.19 um 21:35 schrieb Brandon Allbery:
> And, well, it's a computer language. "Proper
> purity" not gonna happen in general, unless the result is a useless toy.
I do not think that the limitations from Haskell's design choices can be
generalized to all programming languages in this way.
Purity (i.e. no side effects) is easy in strict languages, for example.
In a nonstrict language, you'd need a proof of termination to have
purity (nontermination is impure).
Another approach would be to control impurities. Based on the
observation that all code is impure, such as heating the CPU, taking
time, increasing CPU counters, and we do not care about these
impurities. One could design a language where one could e.g. write a
completely impure logger, call it from pure code, and statically
determine that these impurities do not affect the pure code.
While I think that your pessimism is justified for Haskell where pretty
fundamental design choices would have to be reverted, I conclude it is
not necessarily justified in the generality stated.
Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
--