So would this *improve* error message quality for new users? Defaults that make it easier for haskellers old and new both are a tough balance to make! On Sun, Jan 12, 2014 at 6:40 PM, Dan Frumin wrote:

Hi!

...

On 13 Jan 2014, at 02:56, Krzysztof Gogolewski wrote:

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.

I do think that having _ both as a pattern and a hole might be confusing, I can see that. However that's more of a syntax issue, than an issue about default extensions IMO

...

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

---

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

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 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

Perhaps already as part of such a feedback round/bikeshedding opportunity, I'm wondering if I'm the only one who finds the name "TypeHoles" confusing, since as far as I understand, the extension enables holes in *expressions*, not types... I would personally find something like TypedHoles (note the added d) or ExpressionHoles or something similar more intuitive. Not that I have strong feelings about this, though... Note that I haven't actually tried the extension yet, but from the description, it seems like a very nice addition to GHC, so kudos to whoever did the work... Regards, Dominique 2014/1/13 Richard Eisenberg :

Maybe I'm missing something here, but how does specifying TypeHoles make GHC not compliant with Haskell 2010? Turning on TypeHoles should change only error messages. The set of programs that compile (and their meanings) should remain unchanged, by my understanding.

I'm mildly in favor of this change, but I agree that perhaps a conversation on the users list and/or waiting a cycle isn't a bad idea.

Richard

On Jan 13, 2014, at 4:51 AM, Simon Marlow wrote:

...

On 12/01/2014 22:56, Krzysztof Gogolewski wrote:

...

I propose to enable -XTypeHoles in GHC by default.

GHC supports strict Haskell 2010 by default, and enabling any extensions breaks that property. That's why we don't have any extensions on by default.

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

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

I have re-sent the question to glasgow-haskell-users; to avoid duplication, let's continue the thread there.