| And here we know that y=Bool; yet since we don't write the type sig
| directly we can't say it. So GHC's implementation of fundeps rejects
| this program; again it can't be translated into System F.
|
| Conveniently, this is a good example of my other problem with fundeps :-)
| I can work
I think that if you use the HEAD, much of
this will work, if you use the type-equality
notation. But you will probably encounter bugs
too. And in so doing, and reporting them, you'll
be doing us a service.
I did originally intend to try all this with the
HEAD, but one obstacle to this is
| I did originally intend to try all this with the
| HEAD, but one obstacle to this is the lack of recent linux
| binaries in http://www.haskell.org/ghc/dist/current/dist/
Ian is fixing that. We'd missed the fact that the bindists weren't being built.
Hold on a day or two.
Simon
| I'm trying to understand what fundeps do and don't let me do. One
| particular source of confusion is why the following program doesn't
| typecheck:
|
| {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
| module Fundeps where
|
| class Dep a b | a - b, b - a
|
| conv :: (Dep a
On Dec 3, 2007, at 4:02 AM, Simon Peyton-Jones wrote:
GHC's new intermediate language, System FC, is specifically designed
to do this. Currently we're in transition: equality constraints are
starting to work, but fundeps are implemented as they always were.
I hope we can eventually
| Is it really a good idea to permit a type signature to include
| equality constraints among unifiable types? Does the above type
| signature mean something different from a -a? Does the type signature:
| foo :: (a~Bar b) = a - Bar b
| mean something different from:
| foo :: Bar b -
On Mon, 3 Dec 2007, Simon Peyton-Jones wrote:
No, you didn't miss anything. I wouldn't expect anyone to write these
types directly. But it can happen:
class C a b | a-b
instance C Int Bool
class D x where
op :: forall y. C x y = x - y
instance D Int
Jan-Willem Maessen:
Is it really a good idea to permit a type signature to include
equality constraints among unifiable types? Does the above type
signature mean something different from a -a? Does the type
signature:
foo :: (a~Bar b) = a - Bar b
mean something different from:
foo