Status of Haskell'?

[Dan Doel]

As far as I know, MPTCs alone do not have this issue. But functional
dependencies do, as there are at least two ways they can behave. One is the
way they traditionally behave in GHC, and another is the way they would
behave if they were sugar for type families.

I can't think of anything about MPTCs alone that would be a problem, though.


On Sun, Dec 2, 2012 at 2:56 PM, Gábor Lehel <illissius at gmail.com> wrote:

> On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel <dan.doel at gmail.com> wrote:
> > 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.
> >
>
> Out of curiosity, to what degree does MultiParamTypeClasses have this
> issue? It seems to me like one of the few extensions which is
> straightforward, widely implemented, uncontroversial, and very useful.
> For some reason it's been held up by the FDs vs TFs debate, but I
> don't see why it has to be. Vanilla MPTCs on the one hand, and MPTCs
> together with either FDs or TFs on the other hand, serve different use
> cases. If you want a plain type-level relation on types, you use
> MPTCs. If you want some types to be determined by others, then you use
> either FDs or TFs. If we standardize support for the former, that's
> useful, even if we continue to procrastinate on the FDs vs TFs
> question. So if the idea is to do yearly incremental updates to the
> standard, MPTCs looks like the biggest low-hanging fruit to me.
> (Assuming they aren't similarly problematic as RankNTypes.)
>
> --
> Your ship was destroyed in a monadic eruption.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20121202/08d66505/attachment.htm>