Re: [Haskell-cafe] ANN: To Kata Haskellen Evangelion

I'm not convinced that nontermination would be worth redesigning the language - the research implementations seem rough. (Moreover, one of the advantages of laziness is precisely that one can write a function like take that works on both streams and lists). Cheers, Vanessa On 7/31/19 12:54 PM, Joachim Durchholz wrote:

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 mailto:allbery.b@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 mailto:jo@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@gmail.com mailto:allbery.b@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

_______________________________________________ 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.