New GHC Features for 7.10.1 and Beyond

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: New GHC Features for 7.10.1 and Beyond

Kazu Yamamoto (山本和彦)
Hi Gershom,

> 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.

As a member of Mio developers, I don't understand this sentence. Would
you concretely explain what kind of node.js technologies should be
taken into new-new-new-IO Manager?

--Kazu
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: [Haskell-cafe] New GHC Features for 7.10.1 and Beyond

Michael Snoyman



On Tue, Apr 1, 2014 at 8:07 AM, Kazu Yamamoto <[hidden email]> wrote:
Hi Gershom,

> 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.

As a member of Mio developers, I don't understand this sentence. Would
you concretely explain what kind of node.js technologies should be
taken into new-new-new-IO Manager?


It's really simple: node.js is webscale, Mio is not. I'm sorry, but you simply didn't do a good enough job making sure that random packets were lost when sending network traffic, or that writing data to disk may sporadically fail. Better luck next time.

Michael 

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: New GHC Features for 7.10.1 and Beyond

Henning Thielemann-4
In reply to this post by Gershom Bazerman
These are indeed great ideas!

I like especially this one:


Am 01.04.2014 06:37, schrieb Gershom Bazerman:

> 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.

I think quantum support would justify to give the compiler an according
name like QHC. Or if it is released on days like today, AHC would also
be a good name.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: New GHC Features for 7.10.1 and Beyond

Jason Dagit-3
In reply to this post by Gershom Bazerman



On Mon, Mar 31, 2014 at 9:37 PM, Gershom Bazerman <[hidden email]> wrote:
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.

Thanks Gershom!

I was going to wait till things were more mature before announcing them, but given the enthusiasm generated by your post I think I'll share what we've been working on early.

Given the importance of BigData in today's business world and the complexities of writing software to support it, we have started working on an extension to Haskell to make BigData the language of choice for BigData applications.

The first hurdle we face is how to represent BigData. Previously, we could work with the data but not give it a consistent or unified type. The data was simply too large! To make the representation as natural and manageable as possible we have introduced -XBigTypes.

Note: For technical reasons this also implies -XImpredicativeTypes and allows construction of infinite types. With these sorts of restrictions lifted we are able to construct much larger types than before such as the type of all types and the type a such that `a = [a]`.

Jason

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries