Re: [Haskell] Status of Haskell'?
On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares <nate@so8r.es> wrote:
This standardization process amounts to "endorsement of existing features" which seems like not a bad process at all. It makes the standard descriptive rather than predictive.
+1. I agree generally with Gabor's points -- GHC is in the drivers seat. But at some point we should take a look at all the things GHC has made that did pay off and that are good and make them official.
I'd very much like to see that endorsement happen soon, even if it's not aggressive.
Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me. Maybe as some kind of useful in-between point, the GHC folks could figure out which extensions they like enough that they would, modulo all the details getting figured out and specified, be in favor of them going into a new standard, and fold all of them into a new LANGUAGE definition? So then you would write {-# LANGUAGE HaskellNext #-}, or HaskellGHC, or something like that, to enable all of them in one go. That wouldn't require specifying things down to the tiniest details (which is what a standard requires), but only at the granularity of particular extensions, which is what people seem to be looking for. Maybe instead of the GHC people deciding it, there could be some kind of community process (such as a vote). (And yeah, this sounds eerily similar to -fglasgow-exts, which is what we got rid of in favor of LANGUAGE pragmas, but maybe the fact that -fglasgow-exts turned mostly all extensions on indiscriminately, whereas this would be a curated subset, is a significant enough difference to turn it from a bad idea into a good one.) -- Your ship was destroyed in a monadic eruption.
On Sat, 1 Dec 2012, Gábor Lehel wrote:
On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares <nate@so8r.es> wrote:
+1. I agree generally with Gabor's points -- GHC is in the drivers seat. But at some point we should take a look at all the things GHC has made that did pay off and that are good and make them official.
I'd very much like to see that endorsement happen soon, even if it's not aggressive.
Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me.
In my opinion it is a good thing if people feel bad about a lot of LANGUAGE pragmas at top of their modules. For me the number of LANGUAGE pragmas is a (reciprocal) measure of how much effort the programmer invested in cleaning up the code. In the past I removed a lot of FlexibleInstances, FlexibleContexts, UndecidableInstances, TypeSynonymInstances, PatternGuards and _improved_ the code this way. The need for generalized instances is often caused by badly designed classes or types. For me many extensions are a way to get a working implementation quickly from which I can derive a simpler one by throwing out extensions successively. I would also like to tell students that if they need to enable language extensions (or specific set of extensions) then they are solving a task in a too complicated way. I like to support Gábors arguments. We should have multiple implementations before standardization. E.g. I remember how TypeFamilies have evolved over the time or how the interaction of the forall quantifier with ($) changed between versions of GHC - how can we get confidence that GHC implemented these features in the most reasonable way?
Hi All, I think that there is more to take into account. Haskell is growing as a language that people use to solve scientific and business problems. It is starting to become more of a working language, which is a very good thing of course. But this also means that Haskell should accommodate the people who are only working with it (not developing the language) and might not have a clue about the developers of the language. I'm somewhere in between where I love to read about the developments (this is my first post) and use it to program robots in my lab (besides some other languages). To accommodate the people who just want to use Haskell, we might have a super-pragma (as previously proposed) and for those gaining skill it should be possible to subtract pragmas until you have turned them all off and you can call yourself a Haskell guru. Mind you, I am not one of those, simply because I have to program in 5 languages for my work. For me, all those pragmas are not a matter of ugliness, but more an annoyance. For starters it is even worse. They ask questions such as: What do I turn on? Did I already find a good pragma tutorial? Why do I need to know about pragmas if it is already difficult to learn the language? By subtracting the pragmas (or turning them off) people can learn what they actually do and improve their code and their thinking about the language. Quite often I need the get something done, and due to time pressure I do not always have the luxury to make the code beautiful. And since it is Haskell (if it compiles it probably does what you want) I do not always care. For many users, pragmas are a Haskell concept that they can live without in the first part of their Haskell programming career (and they just turn a load of them on without even thinking about it what they do, but hey, the code works now!...) I think that we should accommodate the 'working programmers' and make their life a little bit easier, so that it becomes easier to start programming in Haskell and the language can be put to use by more people. This does not exclude having a 'pragma prime' that includes proposals for Haskell' of course. But it would help people starting with Haskell a lot imho. Cheers, Tijn On Sat, Dec 1, 2012 at 12:37 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Sat, 1 Dec 2012, Gábor Lehel wrote:
On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares <nate@so8r.es> wrote:
+1. I agree generally with Gabor's points -- GHC is in the drivers seat. But at some point we should take a look at all the things GHC has made that did pay off and that are good and make them official.
I'd very much like to see that endorsement happen soon, even if it's not aggressive.
Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me.
In my opinion it is a good thing if people feel bad about a lot of LANGUAGE pragmas at top of their modules. For me the number of LANGUAGE pragmas is a (reciprocal) measure of how much effort the programmer invested in cleaning up the code. In the past I removed a lot of FlexibleInstances, FlexibleContexts, UndecidableInstances, TypeSynonymInstances, PatternGuards and _improved_ the code this way. The need for generalized instances is often caused by badly designed classes or types. For me many extensions are a way to get a working implementation quickly from which I can derive a simpler one by throwing out extensions successively. I would also like to tell students that if they need to enable language extensions (or specific set of extensions) then they are solving a task in a too complicated way.
I like to support Gábors arguments. We should have multiple implementations before standardization. E.g. I remember how TypeFamilies have evolved over the time or how the interaction of the forall quantifier with ($) changed between versions of GHC - how can we get confidence that GHC implemented these features in the most reasonable way?
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
* Tijn van der Zant <robotijn@gmail.com> [2012-12-01 10:00:31+0100]
Why do I need to know about pragmas if it is already difficult to learn the language?
Exactly. In an ideal world, where the language standard corresponds to what people perceive as being standard, beginners shouldn't know or care about pragmas, which by definition enable non-portable and experimental features. And the last thing a beginner should do is to enable ALL of those obscure features.
(and they just turn a load of them on without even thinking about it what they do, but hey, the code works now!...)
That is an unfortunate situation in which we are now, and which could be improved by releasing a new standard incorporating the most tested and widely-used features. Roman
2012/12/1 Tijn van der Zant <robotijn@gmail.com>:
I think that there is more to take into account. Haskell is growing as a language that people use to solve scientific and business problems. It is starting to become more of a working language, which is a very good thing of course. But this also means that Haskell should accommodate the people who are only working with it (not developing the language) and might not have a clue about the developers of the language. I'm somewhere in between where I love to read about the developments (this is my first post) and use it to program robots in my lab (besides some other languages). To accommodate the people who just want to use Haskell, we might have a super-pragma (as previously proposed) and for those gaining skill it should be possible to subtract pragmas until you have turned them all off and you can call yourself a Haskell guru. Mind you, I am not one of those, simply because I have to program in 5 languages for my work. For me, all those pragmas are not a matter of ugliness, but more an annoyance. For starters it is even worse. They ask questions such as: What do I turn on? Did I already find a good pragma tutorial? Why do I need to know about pragmas if it is already difficult to learn the language? By subtracting the pragmas (or turning them off) people can learn what they actually do and improve their code and their thinking about the language. Quite often I need the get something done, and due to time pressure I do not always have the luxury to make the code beautiful. And since it is Haskell (if it compiles it probably does what you want) I do not always care. For many users, pragmas are a Haskell concept that they can live without in the first part of their Haskell programming career (and they just turn a load of them on without even thinking about it what they do, but hey, the code works now!...) I think that we should accommodate the 'working programmers' and make their life a little bit easier, so that it becomes easier to start programming in Haskell and the language can be put to use by more people. This does not exclude having a 'pragma prime' that includes proposals for Haskell' of course. But it would help people starting with Haskell a lot imho.
Thank you for highlighting the many ways in which pragmas are a problem from a practical point of view. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
* Henning Thielemann <lemming@henning-thielemann.de> [2012-12-01 00:37:12+0100]
We should have multiple implementations before standardization.
Alternative implementations already exist for lots of extenstions, see http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions Roman
2012/11/30 Gábor Lehel <illissius@gmail.com>:
Well, I'm not so sure it's a great idea to just bake "what GHC does at this moment" (for any particular extension) into the standard without really thinking about it. Even then, you have to figure out, in great detail, what GHC does, and write it all down! That's not negligible effort, either. And the alternative is to also publicly discuss and hash all of it out down to the little tiny gritty stuff. But wanting to write a new standard (big effort!) just to get rid of some pragmas and make people feel better (small payoff!) feels like a mismatch to me.
It is a large payoff, considering the thousands and thousands of people that it creates a small payoff for: people writing Haskell, people learning Haskell, people teaching Haskell. A standard is a lot of effort for a handful of people. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B
participants (5)
-
Gábor Lehel -
Henning Thielemann -
Jason Dusek -
Roman Cheplyaka -
Tijn van der Zant