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 <[email protected]> wrote: > Hi! > > > On 13 Jan 2014, at 02:56, Krzysztof Gogolewski <[email protected]> > 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 > > [email protected] > > http://www.haskell.org/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
