<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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_<br>
<br>
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.<br>
<br>
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.<br>
<br>
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”.<br>
<br>
-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).<br>
<br>
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).<br>
<br>
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.<br>
<br>
Finally, I’m very sorry to see that my proposal for youtube syntax
has languished, and I hope it can be revived:
<a class="moz-txt-link-freetext" href="http://www.haskell.org/pipermail/haskell-cafe/2012-April/100527.html">http://www.haskell.org/pipermail/haskell-cafe/2012-April/100527.html</a><br>
<br>
<meta charset="utf-8">
HTH HAND,<br>
Gershom
</body>
</html>