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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
