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 <simo...@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-boun...@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 > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
