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*).
On Wed, Jul 31, 2019 at 1:22 AM Joachim Durchholz
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.
-- brandon s allbery kf8nh allbery.b@gmail.com