[Haskell-cafe] ANN: To Kata Haskellen Evangelion

[Joachim Durchholz]

Haskell is pretty thorough in terms of purity, but it had its blind 
spots around nontermination.
I believe that some thought has been spent on mitigating the issues, but 
I also believe that one would have to redesign parts of the language to 
fully address them.

I agree that one should not count the unsafeXXX functions.

Am 31.07.19 um 14:23 schrieb Cosmia Fu:
> 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.
> 
> On Wed, Jul 31, 2019 at 7:15 PM Brandon Allbery <allbery.b at gmail.com 
> <mailto:allbery.b at gmail.com>> wrote:
> 
>     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 <jo at durchholz.org
>     <mailto:jo at durchholz.org>> wrote:
> 
>         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 at gmail.com <mailto:allbery.b at gmail.com>
>     _______________________________________________
>     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.
> 
> -- 
> Sent from my iPhone