<div><div dir="auto">I am not sure what you are talking about, but in the scope of Haskell, even functions or values involving IO are pure if you do not count the unsafeXXX.</div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2019 at 7:15 PM Brandon Allbery <<a href="mailto:allbery.b@gmail.com">allbery.b@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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*).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 31, 2019 at 1:22 AM Joachim Durchholz <<a href="mailto:jo@durchholz.org" target="_blank">jo@durchholz.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 30.07.19 um 21:35 schrieb Brandon Allbery:<br>
> And, well, it's a computer language. "Proper<br>
> purity" not gonna happen in general, unless the result is a useless toy. <br>
<br>
I do not think that the limitations from Haskell's design choices can be <br>
generalized to all programming languages in this way.<br>
<br>
Purity (i.e. no side effects) is easy in strict languages, for example.<br>
<br>
In a nonstrict language, you'd need a proof of termination to have <br>
purity (nontermination is impure).<br>
<br>
Another approach would be to control impurities. Based on the <br>
observation that all code is impure, such as heating the CPU, taking <br>
time, increasing CPU counters, and we do not care about these <br>
impurities. One could design a language where one could e.g. write a <br>
completely impure logger, call it from pure code, and statically <br>
determine that these impurities do not affect the pure code.<br>
<br>
While I think that your pessimism is justified for Haskell where pretty <br>
fundamental design choices would have to be reverted, I conclude it is <br>
not necessarily justified in the generality stated.<br>
<br>
Regards,<br>
Jo<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="m_-6048357576494701049gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Sent from my iPhone</div>