Perhaps we should let type holes be used for one release (so we can get some feedback) before turning it on by default?


On Mon, Jan 13, 2014 at 9:57 AM, Simon Peyton Jones <simonpj@microsoft.com> wrote:

This would be fine by me – it’s a “user-experience” question.

 

It would slightly threaten the notion that GHC is, by default, a Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects non-H2010 programs.  But I think it would be an acceptable bending of this principle, if people wanted it.  Maybe ask ghc-users?

Simon

 

From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Krzysztof Gogolewski
Sent: 12 January 2014 22:56
To: ghc-devs@haskell.org
Subject: Enable TypeHoles by default?

 

Hello,

 

I propose to enable -XTypeHoles in GHC by default.

 

Unlike other -X* flags, holes do not really change meaning of the program, they only change error messages. Instead of "_x not in scope", we effectively get "_x not in scope, its expected type is a -> a". You get it only if you precede the identifier not in scope with underscore, so in some sense you declare the intention of using holes.

 

Two possible issues:

 

(a) If you use -fdefer-type-errors, then a program might compile, while previously it did not. However, we should facilitate compiling with defer-type-errors, so I don't think this is a disadvantage.

 

(b) The identifier _ becomes both a pattern and a hole by default, which might confuse new users.

Reply: I have never seen anyone ask why code such as "Just _ -> _" does not work.

 

IMO the productivity boost by having holes by default outweighs those two objections. I am open to hearing any other possible issues others might find.

 

The change is trivial implementation-wise; add Opt_TypeHoles to the list in languageExtensions Nothing in DynFlags.

 

-KG


_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs