Claus made a suggestion about type error messages:
| Apart from bracketing fully applied type synonyms, the error message
| could be improved by providing the missing bit of information about
| 'Memo':
|
| D:\home\Haskell\tmp\desktop\types.hs:11:11:
| Couldn't match expected type
Simon Peyton-Jones wrote:
NoMatchErr.hs:20:11:
Couldn't match expected type `Memo d'
against inferred type `Memo d1'
NB: `Memo' is a (non-injective) type function
In the second argument of `(.)', namely `appl'
In the expression: abst . appl
In the
| But the core part of my suggestion (which this example was meant
| to help explain) remains attractive, at least to me: somewhere during
| type inference, GHC *does* unify the *apparently free* 'd' with an
| internal type variable (lets call it 'd1, as in the type error message)
You are
| But the core part of my suggestion (which this example was meant
| to help explain) remains attractive, at least to me: somewhere during
| type inference, GHC *does* unify the *apparently free* 'd' with an
| internal type variable (lets call it 'd1, as in the type error message)
You are
|Oh now i see what you mean: consider
|f' = abst . (id :: (d-a)-(d-a)) . appl
|which GHC understands to mean
|f' = abst . (id :: forall d a. (d-a)-(d-a)) . appl
|
|GHC infers the type
|f' :: (Fun d) = Memo d a - Memo d a
|Now you are saying that GHC *could* have figured
Matt Morrow:
On Mon, Apr 6, 2009 at 7:39 PM, Manuel M T Chakravarty c...@cse.unsw.edu.au
wrote:
Peter Berry:
3) we apply appl to x, so Memo d1 a = Memo d a. unify d = d1
But for some reason, step 3 fails.
Step 3 is invalid - cf,
On Mon, Apr 6, 2009 at 7:39 PM, Manuel M T Chakravarty c...@cse.unsw.edu.au
wrote:
Peter Berry:
3) we apply appl to x, so Memo d1 a = Memo d a. unify d = d1
But for some reason, step 3 fails.
Step 3 is invalid - cf,
http://www.haskell.org/pipermail/haskell-cafe/2009-April/059196.html.
Basically, type checking proceeds in one of two modes: inferring or
checking. The former is when there is no signature is given; the
latter, if there is a user-supplied signature. GHC can infer
ambiguous signatures, but it cannot check them. This is of course
very confusing and we need
| Here is a variation to make this point clearer:
|
| {-# LANGUAGE NoMonomorphismRestriction #-}
| {-# LANGUAGE TypeFamilies, ScopedTypeVariables #-}
|
| class Fun d where
| type Memo d :: * - *
| abst :: (d - a) - Memo d a
| appl :: Memo d a - (d - a)
|
| f = abst . appl
|
| -- f' ::
On 07/04/2009, Ryan Ingram ryani.s...@gmail.com wrote:
On Mon, Apr 6, 2009 at 2:36 PM, Peter Berry pwbe...@gmail.com wrote:
As I understand it, the type checker's thought process should be along
these lines:
1) the type signature dictates that x has type Memo d a.
2) appl has type Memo d1 a
| Here is a variation to make this point clearer:
|
| {-# LANGUAGE NoMonomorphismRestriction #-}
| {-# LANGUAGE TypeFamilies, ScopedTypeVariables #-}
|
| class Fun d where
| type Memo d :: * - *
| abst :: (d - a) - Memo d a
| appl :: Memo d a - (d - a)
|
| f = abst . appl
|
| -- f' ::
On Mon, Apr 6, 2009 at 7:39 PM, Manuel M T Chakravarty
c...@cse.unsw.edu.au wrote:
Peter Berry:
3) we apply appl to x, so Memo d1 a = Memo d a. unify d = d1
But for some reason, step 3 fails.
Step 3 is invalid - cf,
http://www.haskell.org/pipermail/haskell-cafe/2009-April/059196.html.
On Mon, Apr 6, 2009 at 2:36 PM, Peter Berry pwbe...@gmail.com wrote:
As I understand it, the type checker's thought process should be along
these lines:
1) the type signature dictates that x has type Memo d a.
2) appl has type Memo d1 a - d1 - a for some d1.
3) we apply appl to x, so Memo d1
Peter Berry:
{-# LANGUAGE TypeFamilies, TypeSynonymInstances,
ScopedTypeVariables #-}
The following is a class of memo tries indexed by d:
class Fun d where
type Memo d :: * - *
abst :: (d - a) - Memo d a
appl :: Memo d a - (d - a)
-- Law: abst . appl = id
-- Law: appl . abst
14 matches
Mail list logo
