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 < lemm...@henning-thielemann.de> wrote: > > On Sat, 1 Dec 2012, Gábor Lehel wrote: > > On Fri, Nov 30, 2012 at 11:06 PM, Nate Soares <n...@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 > >
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
