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

Olaf Klinke

30 Jul 2019 30 Jul '19

3:31 p.m.

Isn't the Eq vs Ord problem similar to all sub-classes, e.g. Applicative vs. Monad, Semigroup vs. Monoid, Foldable vs. Traversable? What is the recommended way of coding? The Traversable module for example has default implementations of fmap and foldMap, as Functor and Foldable are superclasses. This suggests it is okay to define the subclass method first and derive the superclass methods from them. But arguments have been put up against this practice in particular cases, e.g. for AMP [1]. Olaf [1] https://mail.haskell.org/pipermail/haskell-cafe/2019-July/131259.html

Show replies by date

Brandon Allbery

30 Jul 30 Jul

3:35 p.m.

New subject: ANN: To Kata Haskellen Evangelion

Deriving in that way is more of a question of which breaks more code, I think. Or avoiding breaking code vs. purity arguments, which worry me at least somewhat less because that horse left the stable with Haskell 98 twisting Monad out of shape (granting we're trying to fix at least part of it now), if not earlier. And, well, it's a computer language. "Proper purity" not gonna happen in general, unless the result is a useless toy. But Haskell strives to be usable. On Tue, Jul 30, 2019 at 3:31 PM Olaf Klinke wrote:

...

Isn't the Eq vs Ord problem similar to all sub-classes, e.g. Applicative vs. Monad, Semigroup vs. Monoid, Foldable vs. Traversable? What is the recommended way of coding? The Traversable module for example has default implementations of fmap and foldMap, as Functor and Foldable are superclasses. This suggests it is okay to define the subclass method first and derive the superclass methods from them. But arguments have been put up against this practice in particular cases, e.g. for AMP [1].

Olaf

[1] https://mail.haskell.org/pipermail/haskell-cafe/2019-July/131259.html

_______________________________________________ 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

Joachim Durchholz

31 Jul 31 Jul

1:21 a.m.

New subject: ANN: To Kata Haskellen Evangelion

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

Brandon Allbery

6:15 a.m.

New subject: ANN: To Kata Haskellen Evangelion

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

Cosmia Fu

8:23 a.m.

New subject: ANN: To Kata Haskellen Evangelion

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

Joachim Durchholz

1:54 p.m.

New subject: ANN: To Kata Haskellen Evangelion

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

Vanessa McHale

4:33 p.m.

New subject: 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.

Raoul Duke

4:41 p.m.

New subject: lazy evangelion

...

...
(Moreover, one of the advantages of laziness is precisely that one can write a function like take that works on both streams and lists).

surely that’s not the only way to get such polymorphism in our programming

systems? the “precisely” word there makes it sound to me like people think it is better than any alternative specifically for this use case?

Brandon Allbery

5:02 p.m.

New subject: lazy evangelion

For one, there's ad-hoc overloading, including typeclasses, but those kinds of solutions have their own drawbacks. On Wed, Jul 31, 2019 at 4:41 PM Raoul Duke wrote:

...

...
(Moreover, one of the advantages of laziness is precisely that one can write a function like take that works on both streams and lists).

surely that’s not the only way to get such polymorphism in our programming systems? the “precisely” word there makes it sound to me like people think it is better than any alternative specifically for this use case?

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

Vanessa McHale

5:36 p.m.

New subject: lazy evangelion

Well, I am not aware of any - I don't think I can rule them out a priori. Cheers, Vanessa McHale On 7/31/19 3:41 PM, Raoul Duke wrote:

...

> (Moreover, one of the advantages of laziness is precisely that one can write a function like take that works on both streams and lists).

surely that’s not the only way to get such polymorphism in our programming systems? the “precisely” word there makes it sound to me like people think it is better than any alternative specifically for this use case?

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

Raoul Duke

5:43 p.m.

New subject: lazy evangelion

eg https://docs.oracle.com/javase/7/docs/api/java/util/Iterator.html mayhaps? On Wed, Jul 31, 2019 at 14:37 Vanessa McHale wrote:

...

Well, I am not aware of any - I don't think I can rule them out a priori.

Cheers, Vanessa McHale On 7/31/19 3:41 PM, Raoul Duke wrote:

...
(Moreover, one of the advantages of laziness is precisely that one can write a function like take that works on both streams and lists).

surely that’s not the only way to get such polymorphism in our programming systems? the “precisely” word there makes it sound to me like people think it is better than any alternative specifically for this use case?

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

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

Joachim Durchholz

1 Aug 1 Aug

1:50 a.m.

New subject: ANN: To Kata Haskellen Evangelion

Am 31.07.19 um 22:33 schrieb Vanessa McHale:

...

I'm not convinced that nontermination would be worth redesigning the language - the research implementations seem rough.

That all implementations are rough does not imply whether it's possible to do a smooth one or not, just that nobody has a working idea yet. E.g. it is possible that people try to leverage existing work (90% may try to use type system extensions, for example) and find that it is too unwieldy because the existing mechanisms aren't really suitable (e.g. it may be that type systems in general are not very well-suited to expressing termination properties, leading us to the observation that "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).

That's exactly the relevant scenario. Strictly speaking, all functions that iterate over all elements of the list (say, takes its length) are buggy: They will not terminate if given an infinite list. The bad thing here is that in Haskell, generators and lists are exactly the same, so there is no way to make a non-buggy version of such a function. (AFAIK, which doesn't say much because I haven't looked deeply enough into Haskell in the last decade to be sure about this anymore. The language did evolve after all.)

Jerzy Karczmarczuk

4:06 a.m.

New subject: ANN: To Kata Haskellen Evangelion

Le 01/08/2019 à 07:50, Joachim Durchholz a écrit :

...

Strictly speaking, all functions that iterate over all elements of the list (say, takes its length) *are buggy*: They will not terminate if given an infinite list.

I think that you have a curious definition of the term "buggy". This definition is as buggy as the rest of the world (perhaps infinite...), or more. You like to play with words. Now the non-termination is "buggy". Previously the bottom (non-termination) was impure. Do you really want to save the humanity with such statements? Jerzy Karczmarczuk

Joachim Durchholz

4:49 a.m.

New subject: ANN: To Kata Haskellen Evangelion

Am 01.08.19 um 10:06 schrieb Jerzy Karczmarczuk:

...

You like to play with words. Now the non-termination is "buggy". Previously the bottom (non-termination) was impure. Do you really want to save the humanity with such statements?

Nice play with words.

2119

Age (days ago)

2121

Last active (days ago)

List overview

Download

13 comments

7 participants

participants (7)

Brandon Allbery
Cosmia Fu
Jerzy Karczmarczuk
Joachim Durchholz
Olaf Klinke
Raoul Duke
Vanessa McHale

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

tags

participants (7)