
How to contribute to the Haskell ecosystem - psibi
http://www.haskellforall.com/2015/12/how-to-contribute-to-haskell-ecosystem.html
======
jzelinskie
I've noticed more and more recently all of the Haskell code I see uses these
language extensions at the beginning of every file. Some of them do pretty
radical stuff; it seems pretty intimidating that to write an HTTP API-wrapper
you need 5 extensions to the language. Is there a process by which these
extensions get fully added into the language proper?

~~~
chadaustin
It is intimidating indeed. The unfortunate fact today is that you must
understand and use several language extensions to write real production
Haskell code. On the plus side, perhaps the right way to get started is to
write everything out longhand and then when you find yourself asking "Man I
wish the compiler could do all of this for me" then you'll know what extension
to enable. :)

Many extensions (ExistentialQuantification, Rank2Types, RankNTypes,
ScopedTypeVariables, TemplateHaskell) are necessary for writing certain types
of code in Haskell. I would not be surprised at all to see them folded into
the next official version of the Haskell language.

Others are very convenient but relatively benign syntax sugar
(RecordWildCards, TupleSections, OverloadedStrings, LambdaCase,
DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveTraversable). These
extensions can obliterate huge amounts of boilerplate that you'd need to write
otherwise.

Others are more experimental and will remain as extensions for a while.

I believe I heard that the Haskell Prime effort is going to start again, and a
new version of the language will integrate the most important and mature
extensions, but I'm not following very closely.
[https://prime.haskell.org/](https://prime.haskell.org/)

~~~
wyager
I heard ScopedTypeVariables is not in line to be added to the next standard. I
thought it was a very innocuous extension, but apparently there are some
reservations about it being difficult to add to certain alternate compiler
types, and the committee wants to avoid favoring GHC's current implementation
over other current and future implementations.

I don't know if this is written down anywhere; it came up in conversation with
a committee member.

~~~
pash
The big problem with ScopedTypeVariables is that it changes the meaning of
existing code by unifying type variables that are not unified today in
standardized Haskell.

It's one of those things that you'd probably do if you were starting with a
blank slate, but it's not worth breaking existing code for when you can
instead get the functionality through an opt-in extension. GHC Haskell's
language extensions are pretty nice that way, but it would be nice to
standardize the extensions to open the (extended) language back up to
alternative implementations.

~~~
dllthomas
I'm inclined to agree with your conclusion, overall.

In this case it's worth noting that the issue is ameliorated by the fact that
ScopedTypeVariables can only change the meaning of code that already uses
other extensions, since it only affects type variables explicitly listed in a
forall, and by default you can't have explicit foralls.

------
danharaj
As a heavy user of Haskell professionally and personally, I think you are a
great person if you write a binding to a C library. Any C library. So long as
you do a reasonably thorough job. Covering the entire surface area of the
library is fantastic.

The barest of C bindings, too. A minimal wrapper for memory management is a
much better binding than one that hides the raw API behind an abstraction that
may or may not be suitable for every use.

~~~
hellofunk
I love to see more information about interop between Haskell and C or C++ and
how to use popular C++ libraries from Haskell.

