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
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@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/