Status of Haskell'?

[Dan Doel]

This is a significant problem for even some of the more ubiquitous
extensions. For instance, there are multiple compilers that implement
RankNTypes, but I would not be surprised at all if programs using that
extension were not portable across implementations (they're not really even
portable across GHC versions).

The problem is that RankNTypes is not just about the fact that you are
allowed to use such types; every compiler must decide on an inference
algorithm that incorporates such types while defaulting to Hindley-Milner.
But, there are several such algorithms, and they have different trade offs
as far as where annotations must be placed, or even whether certain
conceivably well-typed terms are type checkable (for instance, GHC used to
do some level of impredicative instantiation; forall a. a -> a could be
instantiated to (forall a. a) -> (forall a. a); but this no longer works).

So, even if we have ubiquitous agreement on the fact that RankNTypes are
useful, and implementable, we don't have ubiquitous agreement on the
algorithms for implementing them, and which set of trade offs to make. But
any standard would have to nail all that down, or else programs won't be
portable.

And this is not the only extension for which this kind of thing is an issue.

-- Dan


On Sun, Dec 2, 2012 at 6:42 AM, Ross Paterson <ross at soi.city.ac.uk> wrote:

> On Fri, Nov 30, 2012 at 11:05:41PM +0000, Gábor Lehel wrote:
> > Well, I'm not so sure it's a great idea to just bake "what GHC does at
> > this moment" (for any particular extension) into the standard without
> > really thinking about it. Even then, you have to figure out, in great
> > detail, what GHC does, and write it all down! That's not negligible
> > effort, either.
>
> And that is the core of the problem.  The standard isn't just a list
> of approved features.  It needs to describe them in such detail that a
> programmer can tell, from the Report alone, whether a particular program
> is legal, and if so what it's supposed to do.  We don't have that level
> of description for these extensions, and creating it will be a lot of
> hard work.
>
> Relying on "what GHC does at the moment" has obvious risks for
> programmers, it also puts an unfair responsibility on GHC itself.  How can
> they improve a feature if it's current implementation is the "standard"?
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20121202/1bfe4f49/attachment.htm>