Enabling TypeHoles by default

[Austin Seipp]

Hi all,

As a follow up to these, Simon and I discussed it in a call today, and
we're actually both in favor of enabling TypeHoles by default. The
reasoning is as stated: it provides more useful error messages and
doesn't cause any programs to fail to work. It's strictly a
development aide when you have errors.

We probably won't change the name right now however. It's already been
put into Cabal (as a recognized extension,) so the name has propagated
a slight bit. We can however give it a new name and deprecate the old
-XTypeHoles in the future. Or, we could change it, but I'm afraid it's
probably a bit too late in the cycle for other devs to change.

Unless anyone has any major objections, I'll probably implement this
(as Krzysztof suggested in ghc-devs@) later today/tomorrow for the 7.8
branch.

On Mon, Jan 13, 2014 at 3:45 PM, Mateusz Kowalczyk
<fuuzetsu at fuuzetsu.co.uk> wrote:
> On 13/01/14 21:30, Daniil Frumin wrote:
>> 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
>>
>
> Indeed I have seen the ghc-devs post. Using Hole instead of stating a
> type is useful for me to me for two things:
>
> * Causing type errors for type of the expression, for example to
> specialise part of the signature and see what GHC infers for the rest of it
>
> * Easily checking types of the expressions I'm working on inside of the
> function. Sometimes one might lose track of types inside a larger
> expression and it is useful to cause a type error with a hole on one of
> the sub-expressions to see where we're at. GHCi doesn't provide a way to
> check type of subexpressions, only top-level definitions so this is
> particularly useful.
>
> While the second problem can be mitigated in simple situations where we
> have a single symbol expression such as
>
> foo :: Integer -> Integer
> foo x y = x + _y
>
> the ‘_’ does not work for larger expressions. For example, the following
>
> foo :: Integer -> Integer
> foo x y = x + _(y + 3)
>
> does not work as it actually gets translated to
>
> foo :: Integer -. Integer
> foo x y = x + _ (y + 3)
>
> and rather than get the type of (y + 3), we get the type of the function
> which takes that expression. Close but not quite. With _ for types I
> could do
>
> x + (y + 3 :: _)
>
> as opposed to
>
> data Hole
> x + (y + 3 :: Hole)
>
> It'd be great if I could spare myself defining Hole *and* get all the
> information about bindings that _ provides.
>
> --
> Mateusz K.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/