Enable TypeHoles by default?

[Johan Tibell]

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 at 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 at haskell.org] *On Behalf Of *Krzysztof
> Gogolewski
> *Sent:* 12 January 2014 22:56
> *To:* ghc-devs at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140113/31c69b34/attachment.html>