[Haskell] Status of Haskell'?
Tijn van der Zant
robotijn at gmail.com
Sat Dec 1 10:00:31 CET 2012
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
On Sat, Dec 1, 2012 at 12:37 AM, Henning Thielemann <
lemming at 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 at so8r.es> wrote:
>>> +1. I agree generally with Gabor's points -- GHC is in the drivers seat.
>>> at some point we should take a look at all the things GHC has made that
>>> 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
>> 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
> 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell