Enabling TypeHoles by default
difrumin at gmail.com
Mon Jan 13 21:30:05 UTC 2014
On ghc-dev Dominique Devriese has actually proposed changing TypeHoles
to TypedHoles or to something similar, because "TypeHoles" sounds like
you can have holes in types, just like in your example.
But what error message do you want to get if you have a hole in your
type? GHC won't be able to tell you much
On Tue, Jan 14, 2014 at 12:54 AM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 13/01/14 18:42, Krzysztof Gogolewski wrote:
>> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
>> default. Rationale:
>> (1) This way holes are far easier to use; just entering "_" allows to check
>> type of a subexpression, no need of adding "-XTypeHoles".
>> (2) This affects error messages only; i.e. the set of programs that compile
>> stays the same - Haskell 2010. The only exception is that if you use
>> -fdefer-type-errors, then a program with a hole compiles, but this seems
>> fine with philosophy of -fdefer-type-errors.
>> If so: would you like it to be in 7.8 or wait a cycle? My preference is
>> 7.8, two people (John and Richard) suggested 7.10.
> Sounds good. Are there plans to allow TypeHoles to actually sit in place
> of types? In the past I did
> data Hole
> hole :: Hole
> hole = undefined
> foo :: Integer -> Integer
> foo x = hole
> bar :: Integer -> Hole
> bar x y = x + y
> to cause type errors that could guide me. I now don't have to resort to
> the first use in ‘foo’ but I still have to define my own Hole type in ‘bar’.
> Mateusz K.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users