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 <difru...@gmail.com> wrote:

> Hi!
>
> > On 13 Jan 2014, at 02:56, Krzysztof Gogolewski <krz.gogolew...@gmail.com>
> 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
>
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Reply via email to