Enabling TypeHoles by default

[Austin Seipp]

Oops. Resending to list:
-----------------------------------

Right, same goes for every type error in that case though. (We also
ban -fdefer-type-errors in the hackage server, FYI, so it's not like
it can affect released code very much anyway.)

In light of this discussion I've made this change in 235fd88a9:

https://github.com/ghc/ghc/commit/235fd88a9a35a6ca1aed70ff71291d7b433e45e4

I'll submit a change to Cabal to remove its awareness of TypeHoles as
an extension.

P.S. As I wrote this, I realize I should probably change it to
-fwarn-typed-holes, as everyone seemed to have wanted...

On Tue, Jan 14, 2014 at 1:00 PM, Edward Kmett <ekmett at gmail.com> wrote:
> It actually can affect what code compiles with -fdefer-type-errors, but I
> don't feel terribly strongly about that.
>
> -Edward
>
>
>
>
> On Tue, Jan 14, 2014 at 12:23 PM, Joachim Breitner
> <mail at joachim-breitner.de> wrote:
>>
>> Hi,
>>
>> heh, I wanted to throw in the same argument: If its just more elaborate
>> error messages, why do we need a flag for it? So count that as +1 from
>> me.
>>
>> Greetings,
>> Joachim
>>
>>
>> Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
>> > I'm actually more in favor of Richard's proposal of just removing the
>> > flag to be honest, now that he mentioned it. And it's not like it's
>> > much more code.
>> >
>> > In any case, as Duncan informed me we'll have a Cabal release anyway,
>> > so I'll work on sorting this out and enabling it.
>> >
>> > On Tue, Jan 14, 2014 at 10:54 AM, Duncan Coutts <duncan at well-typed.com>
>> > wrote:
>> > > On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
>> > >> I can make another cabal release if needed, if someone submits a pull
>> > >> request with the right fix (i.e. add TypedHoles with TypeHoles as a
>> > >> synonym.)
>> > >
>> > > Thanks Johan, or I'm happy to do it.
>> > >
>> > > Duncan
>> > >
>> > >> On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp <austin at well-typed.com>
>> > >> wrote:
>> > >>
>> > >> > At the very least, Type(d)Holes would never appear explicitly since
>> > >> > it
>> > >> > would be enabled by default. But it might be turned off (but I
>> > >> > don't
>> > >> > know who would do that for the most part.) Cabal at least might
>> > >> > still
>> > >> > need an update.
>> > >> >
>> > >> > In any case, Herbert basically summed it up: the time window is
>> > >> > kind
>> > >> > of close, and we would need to re-release/redeploy a few things
>> > >> > most
>> > >> > likely. I really think it mostly depends on the Cabal team and what
>> > >> > their priorities are. I've CC'd Duncan and Johan for their
>> > >> > opinions.
>> > >> >
>> > >> > On Tue, Jan 14, 2014 at 10:27 AM, Herbert Valerio Riedel
>> > >> > <hvr at gnu.org>
>> > >> > wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
>> > >> > >> On 14.01.2014 17:07, Austin Seipp wrote:
>> > >> > >>> We probably won't change the name right now however. It's
>> > >> > >>> already
>> > >> > >>> been put into Cabal (as a recognized extension,) so the name
>> > >> > >>> has
>> > >> > >>> propagated a slight bit. We can however give it a new name and
>> > >> > >>> deprecate the old -XTypeHoles in the future. Or, we could
>> > >> > >>> change
>> > >> > >>> it, but I'm afraid it's probably a bit too late in the cycle
>> > >> > >>> for
>> > >> > >>> other devs to change.
>> > >> > >>
>> > >> > >> Removing a name later on is more time-consuming, with or without
>> > >> > >> deprecation. People get used to the "wrong" name and stop
>> > >> > >> caring, but
>> > >> > >> I can already picture the "type holes are really typed holes"
>> > >> > >> discussions on IRC. I'm strongly in favour of introducing the
>> > >> > >> new name
>> > >> > >> (and the deprecation for the synonym) as early as possible. This
>> > >> > >> change should not be very extensive anyway, so why not slip it
>> > >> > >> in?
>> > >> > >
>> > >> > > Well, as Austin hinted at, this would also require a Cabal-1.18.x
>> > >> > > release in time for the final 7.8, and a recompile of Hackage to
>> > >> > > pick it
>> > >> > > up so that people can start using the new 'TypedHoles' token in
>> > >> > > their
>> > >> > > .cabal files... so there's a bit of coordination required to make
>> > >> > > this
>> > >> > > happen in a timely manner... Or put differently, somebody has to
>> > >> > > care
>> > >> > > enough to invest some time and pull this through :-)
>> > >> > >
>> > >> > > Cheers,
>> > >> > >   hvr
>> > >> > >
>> > >> >
>> > >> >
>> > >> >
>> > >> > --
>> > >> > Regards,
>> > >> >
>> > >> > Austin Seipp, Haskell Consultant
>> > >> > Well-Typed LLP, http://www.well-typed.com/
>> > >> >
>> > >
>> > >
>> > > --
>> > > Duncan Coutts, Haskell Consultant
>> > > Well-Typed LLP, http://www.well-typed.com/
>> > >
>> > >
>> >
>> >
>> >
>>
>> --
>> Joachim “nomeata” Breitner
>>   mail at joachim-breitner.de • http://www.joachim-breitner.de/
>>   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
>>   Debian Developer: nomeata at debian.org
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/