New GHC Features for 7.10.1 and Beyond

[Gershom Bazerman]

There's been lots of exciting work going into the forthcoming GHC 7.8.1 
release. But even with all these new features, our language is far from 
complete and I wouldn't want the GHC team to rest on their laurels. 
Especially with so much renewed community involvement in GHC 
development, it seems appropriate to share some ideas some of us have 
been discussing for future releases, and take a poll of community 
consensus regarding which ones people might be excited to jump in and 
help out with, or might find particularly helpful.

One important area that needs work is exceptions. These are famously 
difficult, and many libraries have been written to provide checked 
exceptions, or unify error and exceptions in various ways. It seems to 
me that the problem, all along, has been that we've decided to give 
Haskell _imprecise exceptions_ with special semantics. It would 
alleviate a great deal of confusion if we implemented a 
-fprecise-exceptions flag that remedied this.

Additionally, while we have long known that Haskell is not a "lazy" 
language but a "non-strict" one, our leading compiler only rarely takes 
advantage of this. It is well known that for every program there is a 
reduction strategy that preserves non-strict semantics while using as 
few reductions as possible. This is known as the "optimal reduction" 
strategy, and it is calculable and well understood. We should put some 
work into a -foptimal-reduction flag.

Another important area of research is quantum computation. The D-Wave 
Two, with 512 qbits, is a commercially available quantum computer now 
deployed in a few leading institutions. As more and more people begin to 
purchase D-Wave systems for home hacking, every language worth its salt 
will need to be able to target this system. Now that cross compilation 
is more fully supported, it would be good to start putting work into a 
dwave backend.

We've also seen a lot of interest in distribution and cloud computing. 
 From the articles I've read, efficient concurrent programming involves 
using node.js, so I think we should put some work into writing a 
new-new-new-IO Manager built on top of this technology.

Furthermore, it's ridiculous that while Haskell allows simple concurrent 
and distributed programming, it offers no simple way to set up a 
distributed environment. Work should be put into a compiler mode that 
provisions cloud resources automatically and distributes the target 
binary among them, with a flag such as: -fvia-s3 _credit_card_number_

There are a few cases where a good idea in GHC can be taken further, and 
I don't know why we haven't tried already. For example, we've found that 
despite introducing some occasional problems, the state hack also has 
drastically improved performance. Since it works so well, we should 
provide a dual to -fno-state-hack, -fmore-state-hack, for those who 
really need every last drop of performance.

Similarly, now we have type holes that let us see what types should be 
inserted in various spots. -fvalue-holes is the next logical step, to 
tell us what terms we should be writing.

Also, while we've put so much emphasis on correctness, we've also 
loosened the bolts optionally the other way, with flags such as 
-XIncoherentInstances. Along the same lines, I would like to introduce 
-XImpossibleInstances to let us express such useful things as "instance 
Int String," "instance IO Comonad," and "instance data if".

-fdefer-type-errors allows us to defer type errors to runtime. Having 
spent some time with JavaScript lately, I think this doesn't go nearly 
far enough. It would be good to run programs with other sorts of 
problems as well, for educational purposes and for quick hacking. So 
work should be put into a -fdefer-scope-errors flag, as well as 
-fon-error-resume-next, which has done wonders for the resilience of 
Visual Basic code (see also the wildly useful ability to set the top 
level error handler in PHP).

With all these features put together, we have a powerful new way to 
approach Haskell programming, and it would be good to enable them by 
default on .ilhs files (illiterate haskell).

It also was pointed out to me recently by Jason Dagit that while we have 
had debates and confusion over closed and open type families and 
functions for years, topologists have solved this problem elegantly. 
With some basic point set topology under one's belt, a 
-XClopenTypeFamilies extension seems almost trivial to implement.

Finally, I'm very sorry to see that my proposal for youtube syntax has 
languished, and I hope it can be revived: 
http://www.haskell.org/pipermail/haskell-cafe/2012-April/100527.html

HTH HAND,
Gershom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140401/403f62ad/attachment.html>