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 MPTC
On Sun, Dec 2, 2012 at 7:06 PM, Dan Doel 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
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
On Fri, Nov 30, 2012 at 11:05:41PM +, 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 do
Me too, if I can.
On Sun, Dec 2, 2012 at 10:23 AM, Stefan Holdermans wrote:
> Simon wrote:
>
> > I’m sure that any solution will involve (as it did in earlier stages)
> motivated individuals who are willing to take up leadership roles in
> developing Haskell’s language definition. I’m copying
Simon wrote:
> I’m sure that any solution will involve (as it did in earlier stages)
> motivated individuals who are willing to take up leadership roles in
> developing Haskell’s language definition. I’m copying this to the main
> Haskell list, in the hope of attracting volunteers!
I, for one
